Closed
Bug 1306500
Opened 8 years ago
Closed 6 years ago
Cache-Control of Subresource Truncated after Second Visit
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: foaminator, Assigned: mayhemer)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(5 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160922113459 Steps to reproduce: 1. Clear the browser's cache 2. Enter URL and hit enter to load page 3. Verify correct Cache-Control settings of subresource via debugger and in about:cache (correct value is "max-age=0, public, must-revalidate") 4. Put cursor in address bar and hit enter to go to address again 5. Debugger shows subresource was picked up from the browser's cache which is confirmed by about:cache (response-head's Cache-Control is now truncated to "must-revalidate") This is from a proprietary Angular 1.5 application and the subresources that fail in this way are ngIncluded. I don't think that should matter as this sequence of events corrupts the Cache-Control header in the browser, but it may help in reproducing the issue. Since I don't have a minimal case to reproduce this, I'm attaching screenshots with the details. They are: 00_Entry_Not_In_Cache = Performed a Clear Cache from Options; this confirms the entry is not cached 01_Correct_Response_Headers = On initial load, the subresource was retrieved from the server and has the correct response headers 02_Entry_With_Complete_Cache_Control = The browser has the complete and correct Cache-Control value for this entry 03_Entry_Now_Cached = After step 4 (address bar Enter on same URL), the debugger shows the subresource was returned from cache and the Cache-Control header is now truncated 04_Entry_Cache_Control_Truncated = The cache entry now has a truncated Cache-Control, yet the original response headers are still correct My guess is some code path is not copying the entire list of Cache Control directives from the original-response-headers to the response-head. I've tried a few different Cache-Control strings and the truncation seems to leave just the last directive. Also, after the response-head's Cache-Control is truncated to "must-revalidate", it does not revalidated; it uses the cached copy. This may be a secondary issue. Actual results: The subresource file was loaded from the browser's cache instead of checking the server for a new version. Expected results: The Cache-Control settings should have forced the browser to check the server for changes to the subresource with a 304 or an updated resource being returned.
Reporter | ||
Comment 1•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
Attachment #8796345 -
Attachment description: Performed a Clear Cache from Options; this confirms the entry is not cached → 00 Performed a Clear Cache from Options; this confirms the entry is not cached
Reporter | ||
Comment 2•8 years ago
|
||
Reporter | ||
Comment 3•8 years ago
|
||
Reporter | ||
Comment 4•8 years ago
|
||
Reporter | ||
Comment 5•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Updated•8 years ago
|
Whiteboard: [necko-next]
Comment 6•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
Comment 7•6 years ago
|
||
This seems worth fixing. Can you have a look?
Assignee: nobody → odvarko
Flags: needinfo?(odvarko)
Whiteboard: [necko-next] → [necko-triaged]
Comment 8•6 years ago
|
||
you meant other Honza
Assignee: odvarko → honzab.moz
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 9•6 years ago
|
||
I'm afraid this is intentional. We allow stalled content for page loads that are navigated to (pressing enter in address bar) under certain conditions (may be heuristic calc), which is different from e.g. F5 (we force reval). I don't recall all the details from the top of my head, tho. It's always a sensitive thing to change our caching policies related to specifically top level page loads (we can break BF cache, POSTs). So, if we want to modify anything here, it needs some evaluation first. The bit about modifying the C-C resp header seems weird to me. Necko doesn't do anything like that to my knowledge. This may also somewhat relate to 1468476, another bug complaining the opposite - that we validate to much. foaminator, I would like to ask you two things: 1. please retest with current Firefox Nightly 2. If a minimal use case can't be provided, a log may confirm/dispute some details, please see [1] and when you find time, capture them and send to e.g. my bugzilla email. This is definitely not a P2 bug. Thanks. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Flags: needinfo?(odvarko)
Flags: needinfo?(honzab.moz)
Flags: needinfo?(foaminator)
Priority: P2 → P3
See Also: → 1468476
Updated•6 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 10•6 years ago
|
||
There still may be an extension or web content to blame. UNCONF.
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Reporter | ||
Comment 11•6 years ago
|
||
Re-tested on 63.0.1 (64-bit on Windows 10) and unable to reproduce. For posterity, tested all permutations of the following: 1) With addons NoScript and AdBlock Plus enabled and disabled 2) With dev tools console open and closed 3) With dev tools network tab "Disable Cache" checked and unchecked 4) With page reload via F5, reload button, and address bar enter IMHO this issue can be closed.
Flags: needinfo?(foaminator)
Assignee | ||
Comment 12•6 years ago
|
||
Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•