Opened 9 years ago
Closed 9 years ago
#27211 closed Bug (fixed)
Include HTTP-caching headers to "304 Not Modified" responses
| Reported by: | Rinat Khabibiev | Owned by: | Rinat Khabibiev |
|---|---|---|---|
| Component: | HTTP handling | Version: | 1.10 |
| Severity: | Normal | Keywords: | |
| 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 )
According to RFC7232 all "304 Not Modified" responses must include "Cache-Control" and "Expires" headers that would have been sent in a corresponding "200 OK" response.
Change History (7)
comment:1 by , 9 years ago
| Component: | Core (Cache system) → HTTP handling |
|---|
comment:2 by , 9 years ago
The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary.
Taken from RFC7232: https://tools.ietf.org/html/rfc7232#section-4.1.
Usually responses with 200 code will include such headers (e.g. from views decorated with cache_page), so according to the RFC responses with 304 code must also include them.
comment:3 by , 9 years ago
| Status: | new → assigned |
|---|
comment:4 by , 9 years ago
| Description: | modified (diff) |
|---|
comment:5 by , 9 years ago
| Description: | modified (diff) |
|---|---|
| Has patch: | set |
| Triage Stage: | Unreviewed → Accepted |
| Type: | New feature → Bug |
comment:6 by , 9 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Note:
See TracTickets
for help on using tickets.
I didn't spot a reason for the behavior in the original ticket (#580). Can you motivate this change with an example? You say "most browsers can cache responses with 304 HTTP code" -- any idea why all browsers don't?