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)

49 Branch
x86_64
Windows 10
defect

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.
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
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Component: Untriaged → Networking: Cache
Product: Firefox → Core
Whiteboard: [necko-next]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
This seems worth fixing. Can you have a look?
Assignee: nobody → odvarko
Flags: needinfo?(odvarko)
Whiteboard: [necko-next] → [necko-triaged]
you meant other Honza
Assignee: odvarko → honzab.moz
Flags: needinfo?(honzab.moz)
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
There still may be an extension or web content to blame.  UNCONF.
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
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)
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.

Attachment

General

Creator:
Created:
Updated:
Size: