1198747 - Cache-Control: max-age=N header ignored

Status: RESOLVED DUPLICATE of bug 1087320

(Core :: Networking: Cache, defect)

Description

[joe.pearson]

Attachment: Screen Shot 2015-08-26 at 9.53.05 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9

Steps to reproduce:

Visit a page with a Web Service JSONP call, such as http://www.weather.com/weather/today/l/USGA0028:1:US and see that the following request is made http://dsx.weather.com/wxd/v2/(Astro/en_US/0/15;15DayForecast/en_US;NCRecord/en_US)/USGA0028:1:US?api=7bb1c920-7027-4289-9c96-ae5e263980bc&jsonp=angular.callbacks._2

The response has a Cache-Control: max-age=N header and no Expires or ETag headers.


Actual results:

The browser is holding onto the response until the browser cache is cleared.  The resource is not being re-requested over the network when the page is reloaded.  This results in the page displaying old data.


Expected results:

The response should have been removed from the cache when the max-age=N seconds had passed.  Upon page reload, the request should have been made over the network for the resource, not pulled from cache.

Comment 1

[:Harald Kirschner :digitarald]

ni? :jduell who might be able to identify the source of the issue.

Comment 2

[Potch [:potch]]

When I refresh the page with and without cache enabled, I observe that the server responses have Varnish headers, and when refreshing, see the same X-Varnish header values consistently. Could the varnish cache have something to do with the behavior you are observing?

Comment 3

[joe.pearson]

The page currently has a ?_=[epoch_time] query parameter dynamically appended to each call (only for Firefox), thus cache-busting.  You won't be able to re-create the bug on the page at present.

The symptoms that we observed were that some Firefox 39 & 40 visitors on any OS were holding onto the initial response indefinitely.  Since we did not see this behavior with curl or any other browser, we determined that the issue was most likely not on any serving tier or caching layer server-side.  

Likewise, we guessed that the issue was in Firefox's caching logic since browsers that exhibited the bug were able to retrieve a fresh copy with updated data when hitting the same URL in a new Private Window (assuming that the Private Window uses a new instance of the cache), but not the original window despite reloads and closing and re-opening the browser.  The only way to force the browser to get a new copy was to delete/clear the browser's cache.

Comment 4

[Bill Walker [:bwalker] [@wfwalker]]

Hi(In reply to joe.pearson from comment #3)
> The page currently has a ?_=[epoch_time] query parameter dynamically
> appended to each call (only for Firefox), thus cache-busting.  You won't be
> able to re-create the bug on the page at present.

Hi Joe,

Can you give us some new Steps To Reproduce? That would be super helpful.

-Bill

Comment 5

[Bill Walker [:bwalker] [@wfwalker]]

Potentially related?

bug 1087320, especially https://bugzilla.mozilla.org/show_bug.cgi?id=1087320#c6

Comment 6

[amadali]

Hello,
Im a developer at weather.com. I will try and get a fiddle that can demonstrate the issue.

Comment 7

[joe.pearson]

(In reply to Bill Walker [:bwalker] [@wfwalker] from comment #5)
> Potentially related?
> 
> bug 1087320, especially
> https://bugzilla.mozilla.org/show_bug.cgi?id=1087320#c6

Plausible.  Our charset tag is > 512 bytes from the beginning of the document.  When we get the fiddle up and find a browser to reproduce the issue on, we can move the charset tag up the page and re-test.

Comment 8

[amadali]

Here is a jsfiddle that should illustrate what we sorta have on our website. 
http://jsfiddle.net/o7888wt5/6/

Run the test with the network tab open and you should see (pending on the affected Firefox versions) that some of the requests are cached longer than their expires times.

Comment 9

[Jason Duell]

Given comment 7 I suspect this is a dupe of bug 1087320, and as bz mentions in that bug, your fastest fix will be to make sure your charset tag is <512 bytes from the start of your document.

That said, we should fix the bogus behavior where LOAD_FROM_CACHE gets propagated to the entire load group (i.e. we should figure out some way to set flags for document loads that are just for that load, not the whole loadGroup).  But that may be a good chunk of work, and given that this bug is getting hit quite infrequently on the net (with all due apologies of course: it's a bug and our fault), it may not be the best use of our resources to fix it when there's a simple workaround.

I want :michal to confirm that I'm right before we dupe this.

Comment 10

[amadali]

Sorry for the late reply. What items are considered as part of the 512 bytes? Are IE conditional rules part of the 512?

https://gist.github.com/roastlechon/c3b201ce5c5d698d5edc

The gist shows what the content is. I used an online tool and copy pasted the text and it doesnt seem to be hitting the 512 limit if I dont include the IE conditional rules. If I included the rules, its over 1kb

http://bytesizematters.com/

Comment 11

[joe.pearson]

(In reply to Jason Duell [:jduell] (needinfo? me) from comment #9)
> Given comment 7 I suspect this is a dupe of bug 1087320, and as bz mentions
> in that bug, your fastest fix will be to make sure your charset tag is <512
> bytes from the start of your document.

We're in the process of moving the tag higher.  This involves removing conditional comments for supporting legacy IE browsers.  In the meantime, I was wondering if bug 1087320 is really applicable, since the Content-Type of the pages in question is "text/html; charset=utf-8" which would seem to indicate that the browser should ignore any meta charset tags in the HTML itself.  Do you agree that specifying the charset in the HTTP headers would mean that the browser would ignore any meta charset tags in the markup?