Changes between Initial Version and Version 3 of Ticket #4994
- Timestamp:
- Oct 12, 2016, 12:37:59 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #4994
- Property Triage Stage Unreviewed → Ready for checkin
- Property Resolution → fixed
- Property Status new → closed
- Property Easy pickings unset
- Property Severity → Normal
- Property Type → Bug
- Property UI/UX unset
-
Ticket #4994 – Description
initial v3 1 1 The CommonMiddleware functionality generates a new HTTP Response object (304) when the E-Tag matches. This new response does not include the Set-Cookie header, which then breaks the login page from django.contrib.auth.views.login. 2 2 3 This also violates the Cookie specification (see [http://wp.netscape.com/newsref/std/cookie_spec.html]): If a proxy server receives a response which contains a Set-cookie header, it should propagate the Set-cookie header to the client, regardless of whether the response was 304 (Not Modified) or 200 (OK). 3 This also violates [https://curl.haxx.se/rfc/cookie_spec.html the Cookie specification]: If a proxy server receives a response which contains a Set-cookie header, it should propagate the Set-cookie header to the client, regardless of whether the response was 304 (Not Modified) or 200 (OK). 4 5 Apache has [https://bz.apache.org/bugzilla/show_bug.cgi?id=18388 similar behavior]. 4 6 5 7 The attached patch solves this by moving any set cookies over into the new response object.