* ui_ux: => 0
* type: => Bug
* severity: => Normal
* easy: => 0
Old description:
> 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.
>
> 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).
>
> The attached patch solves this by moving any set cookies over into the
> new response object.
New description:
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.
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).
Apache has [https://bz.apache.org/bugzilla/show_bug.cgi?id=18388 similar
behavior].
The attached patch solves this by moving any set cookies over into the new
response object.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/4994#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.