#32191: Not RFC 6265 compliant cookies in contrib.messages.
----------------------------------+---------------------------------------
Reporter: Nico Giefing | Owner: Craig Smith
Type: Bug | Status: assigned
Component: contrib.messages | Version: 3.1
Severity: Normal | Resolution:
Keywords: Cookie malformed | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+---------------------------------------
Comment (by Collin Anderson):
Hi All,
I figure I should probably give some historical context about cookie
quoting for the record. It mostly matches the analysis so far on the
ticket:
When I refactored `request.COOKIE` (`parse_cookie()`) back in 2016, I was
surprised that the cookie RFCs don't accurately describe how browsers
work. I had to test browers myself to figure stuff out. The RFCs gave no
guidance as to how to encode cookies, so there's really no official
standard for how to encode/decode, and in that respect leaving it up to
the application itself to do the encoding could make sense from a Django
perspective. I did also notice that using % url quoting was what a lot of
frameworks were using for encoding, so that is becoming more and more of
an ad-hoc standard, despite not being in the RFC. (Percent encoding makes
it really easy to encode/decode in Javascript.).
In 2016 I decided not to touch this encoding issue because I wanted to
minimize backwards-compatible issues, so I kept using Python's
`http.cookies._unquote()` (slash encoding) for backwards compatibility.
(Again, browsers don't automatically unquote anything in cookies, so it's
not a browser-compatibility thing)
I think long-term it would be great to stop encoding cookies using
`http.cookies. _quote()`, as I think it's really just a python-specific
way of quoting cookies, and as this issue states, it ends up creating
invalid cookies. (invalid according the RFC at least. Browsers don't care
and they work fine with many of what the RFC considers invalid
characters.)
Part of me thinks it would be nice if Django continued to handle cookie
encoding automatically and switch to % encoding, but I think that's going
to lead to double encoding/decoding in some cases with the current api.
Maybe we could have a response.set_cookie('name', 'value',
encode=True/False) to control whether Django applies % encoding or not?
We'd probably also need to have request.cookies.get('name',
decode=True/False).
Anyway, I think the safest and most minimal thing to do is to modify the
messages framework to % url quote cookies as PR 13690 suggests. I don't
have a clear picture for a more general framework-wide fix, but I at least
wanted to write my story down somewhere in case it's helpful.
--
Ticket URL: <https://code.djangoproject.com/ticket/32191#comment:15>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.d30a070066311823a248e06f4677a551%40djangoproject.com.
