#35440: Update parse_header_parameters to leverage the parsing logic from 
(stdlib)
email Message.
-------------------------------------+-------------------------------------
     Reporter:  Natalia Bidart       |                    Owner:  nobody
         Type:                       |                   Status:  new
  Cleanup/optimization               |
    Component:  HTTP handling        |                  Version:  dev
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Description changed by Natalia Bidart:

Old description:

> Following a security report, which was concluded not to be such, the
> Security Team agreed to apply a few improvements to the
> `parse_header_parameters` function from `django/utils/http.py`.
>
> This function was historically using Python's (now deprecated) `cgi`
> module, but in 34e2148fc725e7200050f74130d7523e3cd8507a the code was
> changed by porting the `cgi` implementations into the file to avoid the
> deprecation (this was in the context of #33173). Later on the header
> parsing logic was cleaned up in d4d5427571b4bf3a21c902276c2a00215c2a37cc
> to unify the logic with the one used in the `multipartparser.py` module
> (see #33697).
>
> At the time of the `cgi` deprecation, the
> [https://peps.python.org/pep-0594/#cgi PEP including the deprecation]
> mentions:
>
> > Replacements for the various parts of cgi which are not directly
> related to executing code are: [ ... ] parse_header with
> email.message.Message (see example below)
>
> Providing an explicit example of how close `parse_header` and
> `email.message.Message` are:
>
> {{{#!python
> >>> from cgi import parse_header
> >>> from email.message import Message
> >>> parse_header(h)
> ('application/json', {'charset': 'utf8'})
> >>> m = Message()
> >>> m['content-type'] = h
> >>> m.get_params()
> [('application/json', ''), ('charset', 'utf8')]
> >>> m.get_param('charset')
> }}}
>
> The goal of this ticket is to track the improvement of the current
> `parse_header_parameters` implementation by leveraging the logic from
> `email.message.Message`

New description:

 Following a security report, which was concluded not to be such, the
 Security Team agreed to apply a few improvements to the
 `parse_header_parameters` function from `django/utils/http.py`.

 This function was historically using Python's (now deprecated) `cgi`
 module, but in 34e2148fc725e7200050f74130d7523e3cd8507a the code was
 changed by porting the `cgi` implementations into the file to avoid the
 deprecation (this was in the context of #33173). Later on the header
 parsing logic was cleaned up in d4d5427571b4bf3a21c902276c2a00215c2a37cc
 to unify the logic with the one used in the `multipartparser.py` module
 (see #33697).

 At the time of the `cgi` deprecation, the
 [https://peps.python.org/pep-0594/#cgi PEP including the deprecation]
 mentions:

 > Replacements for the various parts of cgi which are not directly related
 to executing code are: [ ... ] parse_header with email.message.Message
 (see example below)

 Providing an explicit example of how close `parse_header` and
 `email.message.Message` are:

 {{{#!python
 >>> from cgi import parse_header
 >>> from email.message import Message
 >>> parse_header(h)
 ('application/json', {'charset': 'utf8'})
 >>> m = Message()
 >>> m['content-type'] = h
 >>> m.get_params()
 [('application/json', ''), ('charset', 'utf8')]
 >>> m.get_param('charset')
 }}}

 The goal of this ticket is to track the improvement of the current
 `parse_header_parameters` implementation by leveraging the logic from
 `email.message.Message`.

 The Security Team also agreed that it's worth adding some early checks in
 the `parse_header_parameters` function to limit the amount of provided
 semicolons. This would require some investigation as to what would be a
 good threshold, considering that it's likely that more than one semicolon
 may not be necessary in valid HTTP headers.

--
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35440#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f5938a6af-2ea34222-df71-4fc4-8014-ad3bb6b65e2f-000000%40eu-central-1.amazonses.com.

Reply via email to