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

RESOLVED DUPLICATE of bug 428916

Status

()

Core
Networking: Cache
RESOLVED DUPLICATE of bug 428916
3 years ago
2 years ago

People

(Reporter: nate.eborn, Assigned: mayhemer)

Tracking

35 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Created attachment 8559225 [details]
Screenshot of Actual and Expected Results

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
(Reporter)

Comment 2

3 years ago
Created attachment 8559587 [details]
Screenshot of example app w/ Firebug console then Firebug network tab visible

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)

Updated

3 years ago
Assignee: nobody → honzab.moz
(Assignee)

Comment 3

2 years ago
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
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 4

2 years ago
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.
(Assignee)

Comment 5

2 years ago
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
(Assignee)

Comment 6

2 years ago
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
(Reporter)

Comment 7

2 years ago
Created attachment 8714888 [details]
Updated screenshot of developer tools network tab with request Cache-Control header highlighted

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
(Assignee)

Comment 8

2 years ago
It's a request header, not response header.  That has no effect on local caching in Gecko.
(Reporter)

Comment 9

2 years ago
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
Last Resolved: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 428916
(Assignee)

Comment 12

2 years ago
(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 ;)
(Reporter)

Comment 13

2 years ago
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.