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

Status: RESOLVED DUPLICATE of bug 428916

(Core :: Networking: Cache, defect)

Description

[nate.eborn]

Attachment: 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.

Comment 1

[Matthias Versen [:Matti]]

I could not reproduce the issue with the testcase and Firefox35

Comment 2

[nate.eborn]

Attachment: 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.

Comment 3

[Honza Bambas (:mayhemer)]

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.

Comment 4

[nate.eborn]

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.

Comment 5

[Honza Bambas (:mayhemer)]

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.

Comment 6

[Honza Bambas (:mayhemer)]

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

Comment 7

[nate.eborn]

Attachment: 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.

Comment 8

[Honza Bambas (:mayhemer)]

It's a request header, not response header.  That has no effect on local caching in Gecko.

Comment 9

[nate.eborn]

My understanding is that Cache-Control is a general header (i.e. can be used with either requests or responses).

Comment 10

[Patrick McManus [:mcmanus]]

(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.

Comment 12

[Honza Bambas (:mayhemer)]

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

Comment 13

[nate.eborn]

Thanks everyone for your help. Sorry for the duplicate.