#4994: Cookies are not sent back for HTTP Not Modified (304) from 
CommonMiddleware
-------------------------------------+-------------------------------------
     Reporter:  colin@…              |                    Owner:  Malcolm
                                     |  Tredinnick
         Type:  Bug                  |                   Status:  closed
    Component:  HTTP handling        |                  Version:  master
     Severity:  Normal               |               Resolution:  fixed
     Keywords:  etags                |             Triage Stage:  Ready for
                                     |  checkin
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

 * 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.

-- 
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 post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.39bd04860e2d0efa392e2ab345a09c5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to