Open Bug 1213734 Opened 10 years ago Updated 2 years ago

Updating HTTP headers with a 304

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: mnot, Unassigned)

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56 Steps to reproduce: http://lxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpResponseHead.cpp#573 lists a number of headers that are ignored with a 304 response updates a cache (if I'm reading the code correctly). It includes ETag, Content-Location and Content-MD5, with the result that these headers cannot be updated by a 304 response. There are legitimate cases for doing so: * An ETag might be upgraded from weak to strong by a server * A Content-Location might be updated * A Content-MD5 might be corrected Unless there's a good reason (e.g., security) why these shouldn't be updated by a 304 from the server, please remove them from that list. While we're at it, it'd be good to know why 'Assume Cache-Control: "no-transform"' implies that Content-Encoding, Content-Range and Content-Type can't be updated by a 304. Is this just an implementation difficulty?
(In reply to mnot from comment #0) > * ETag Bug 1164198 > * Content-Location Bug 109553 > * Content-MD5 Bug 232030 So is this a duplicate of bug 1164198?
Component: Untriaged → Networking: HTTP
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Whiteboard: [DUPEME?]
Good to know WRT ETag. WRT Content-Location and Content-MD5, I'm not saying they should be implemented (whatever that means for a browser); just that they shouldn't be exempted from update upon a 304. E.g., someone might be using it from XHR.
this is all deep legacy stuff. So I'm just guessing at its history too. so I'm with you on c-location and etag.. but haven't gotten my head around md5 yet. (though this is rather a moot point) what is the meaning of a response that says your stored response is the same as before but now it has a different hash? I guess it could be updating from null - but without seeing the variant it seems like asking for trouble more than anything.
Agreed, I think anyone using C-MD5 needs to be careful about it; just don't see any real justification from exempting it from update on a 304 (esp since an intermediary will already be doing so). Part of my interest here is that Chrome is cargo-culting this due to your source; see: https://code.google.com/p/chromium/issues/detail?id=354080
(i.e., if you do end up leaving those in, please at least document *why* they're excepted in source)
Regarding ETag, it is logically impossible to update ETag from a 304 response (see my comment in bug 1164198). IOW, the exemption logic should be assertion.
ETags can be weak validators.
Assignee: nobody → mcmanus
Whiteboard: [DUPEME?] → [DUPEME?][necko-active]
Assignee: mcmanus → nobody
Whiteboard: [DUPEME?][necko-active] → [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.