Skip to content
Snippets Groups Projects
  1. Sep 22, 2020
  2. Sep 21, 2020
  3. Sep 18, 2020
  4. Sep 17, 2020
  5. Sep 16, 2020
  6. Sep 15, 2020
  7. Sep 14, 2020
  8. Sep 11, 2020
  9. Sep 10, 2020
  10. Sep 09, 2020
  11. Sep 08, 2020
  12. Sep 04, 2020
  13. Sep 03, 2020
  14. Sep 02, 2020
  15. Sep 01, 2020
  16. Aug 31, 2020
    • Binod Pant's avatar
      upgrade edx-enterprise 3.7.1 (#24876) · bc5b71f0
      Binod Pant authored
    • Régis Behmo's avatar
      Get rid of lepl deprecation warning by removing rfc6266 dependency (#24059) · ba18d48a
      Régis Behmo authored
      The LEPL dependency was triggering a lot of deprecation warnings of the
      form:
      
          venv/lib/python3.5/site-packages/lepl/matchers/support.py:497:
          DeprecationWarning: inspect.getargspec() is deprecated, use
          inspect.signature() instead
          argspec = getargspec(func)
      
      It turns out that LEPL was only used by the rfc6266_parser package, which
      itself was only used in one place to generate utf8-compliant
      Content-Disposition headers.
      
      This issue was noticed here:
      https://github.com/SWW13/python-rfc6266-parser/issues/2
      Unfortunately it is quite difficult to extract LEPL from the
      rfc6266-parser package.
      
      The rfc6266-parser package (https://pypi.org/project/rfc6266-parser/) is
      itself a fork of the now-unmaintained rfc6266 package
      (https://pypi.org/project/rfc6266/). Thus, it became high time to get
      rid of this package. The FileResponse object can appropriately set the
      Content-Disposition header, and thus replace the rfc6266 functionality,
      since Django 2.0: https://code.djangoproject.com/ticket/16470
      
      In our testing, the FileResponse object correctly set the
      `filename*=utf-8''` value, following the RFC. The only difference is
      that it does not provide "filename" fallback value, as expressed in the
      RFC: https://tools.ietf.org/html/rfc6266#appendix-D
      
      With rfc6266_parser:
      
          >> import rfc6266_parser
          >> rfc6266_parser.build_header("my_file_é.csv", filename_compat="video_urls.csv")
          b"attachment; filename=video_urls.csv; filename*=utf-8''my_file_%C3%A9.csv"
      
      With FileResponse we have:
      
          >> from django.http import FileResponse
          >> import io
          >> response = FileResponse(io.StringIO(), as_attachment=True, filename="my_file_é.csv", content_type="text/csv")
          >> response.get("Content-Disposition")
          "attachment; filename*=utf-8''my_file_%C3%A9.csv"
      
      We consider that this is a sufficiently minor difference, that will
      impact very few browsers.