#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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
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