#4994 closed Bug (fixed)
Cookies are not sent back for HTTP Not Modified (304) from CommonMiddleware
| Reported by: | Owned by: | Malcolm Tredinnick | |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | etags |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
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: 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 similar behavior.
The attached patch solves this by moving any set cookies over into the new response object.
Attachments (1)
Change History (4)
by , 19 years ago
| Attachment: | common-middleware-fix.patch added |
|---|
comment:1 by , 19 years ago
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
comment:2 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:3 by , 10 years ago
| Description: | modified (diff) |
|---|---|
| Easy pickings: | unset |
| Severity: | → Normal |
| Type: | → Bug |
| UI/UX: | unset |
Note:
See TracTickets
for help on using tickets.
Patch for 304 and Cookies