Firefox serving from cache even when Cache-control no-cache is set

RESOLVED DUPLICATE of bug 428916

Status

()

defect
RESOLVED DUPLICATE of bug 428916
5 years ago
4 years ago

People

(Reporter: nate.eborn, Assigned: mayhemer)

Tracking

35 Branch
x86
macOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

1. Visit the site https://www.qzzr.com/widget/quiz/wl/quiz/fi9xdWl6emVzLzY
2. Start taking the quiz


Actual results:

Intermittently, XMLHttp GET requests are served from the cache despite a 'Cache-Control: no-cache' header on the request. This is apparent by the answer response not being displayed after the POST of the answer, and also by a GET request not appearing after the POST in the network tab of developer tools.

The second attempt to POST then GET results in the expected behavior of the GET returning from the server, not the cache.


Expected results:

Rather than hitting the cache, the Cache-Control header is respected and the XMLHttp GET request goes to the server. The request is visible in the network tab, and the updated resource data is reflected in the UI.
I could not reproduce the issue with the testcase and Firefox35
Component: Untriaged → Networking: Cache
Sorry, the previously described behavior is really inconsistent. I don't know how to consistently get the browser in the right state to reproduce, but I did create a contrived example that consistently fails.

Steps to reproduce:
1. Visit https://fathomless-refuge-3745.herokuapp.com/
2. Click increment

Actual results:

Only one XMLHttp GET request is sent over the network, though two XMLHttp GET requests are triggered.

The two requests are apparent in the Firebug console tab, and that only one request was sent to the server is apparent int he network tab.

Expected results:

The "Cache-Control: no-cache" header is respected, and two GET requests occur.
Assignee: nobody → honzab.moz
Sorry for taking that long time to look at this, but the test case no longer works (Application Error).  If you can provide a new test case I will gladly look again (sooner).  Closing in the mean time as INCOMPLETE.  I also suspect bug 1087320 as a duplicate, but cannot verify that.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Thanks, Honza, for checking it out. The app is on a free dyno on Heroku so it occasionally falls asleep. If you wait 20 seconds or so after seeing the initial Application Error message and then refresh the page the app should wake back up and load as expected. Sorry for the inconvenience.
Not sure anything has changed, but I don't see no-cache being set on responses to 'https://fathomless-refuge-3745.herokuapp.com/counter' XHR request.  Neither POST nor GET.  Also, XHR POST never reuses cache.  Each post has a unique ID FPOV of the cache.

I can see POST, GET, GET in series when pressing the increment button.  The second GET (third XHR) goes from the cache, since we can reuse it based on the expiration time (there is age set to 60 mintues - 3600 seconds).

Changing to INVALID.
Resolution: INCOMPLETE → INVALID
And note that the second request (the first of the GETs) doesn't go from the cache because of this code:

http://hg.mozilla.org/mozilla-central/annotate/5f9ba76eb3b1/netwerk/protocol/http/nsHttpChannel.cpp#l6857
Thanks for checking out the bug.

Both GET requests include a 'Cache-Control: "no cache"' header, which for the second GET request is not observed (see attached screenshot).

I realize the example use case is contrived. To easily reproduce the issue I am using two successive GET requests. But in the wild I occasionally observe the same behavior when the order is GET, POST, GET, with the first GET being removed from the subsequent requests by additional time (e.g. 30 sec).

I realize not making two immediately successive requests to a cached resource regardless of the presence of a Cache-Control header may be defensive. I am not sure what the correct behavior is. I just know that I have experienced cases where the Cache-Control header was not being observed in more reasonable cases. But again, those more reasonable cases are more sporadic and I am unable to consistently reproduced the required state.

Thanks again for your time.
Attachment #8559587 - Attachment is obsolete: true
It's a request header, not response header.  That has no effect on local caching in Gecko.
My understanding is that Cache-Control is a general header (i.e. can be used with either requests or responses).
(In reply to nate.eborn from comment #9)
> My understanding is that Cache-Control is a general header (i.e. can be used
> with either requests or responses).

you're right.. in general firefox isn't an intermediary so this is all a little weird, but in this case I think we need to honor it. I'm pretty sure this bug will be dup'd.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 428916
(In reply to Patrick McManus [:mcmanus] from comment #11)
> 
> *** This bug has been marked as a duplicate of bug 428916 ***

Thanks Patrick, I realized we probably have an open bug for this during the last night ;)
Thanks everyone for your help. Sorry for the duplicate.
You need to log in before you can comment on or make changes to this bug.