Some XHR resources are never refreshed

RESOLVED INVALID

Status

()

RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: marco, Unassigned)

Tracking

({regression})

52 Branch
regression
Points:
---

Firefox Tracking Flags

(firefox52 affected)

Details

(URL)

(Reporter)

Description

2 years ago
I've noticed this problem on https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxaurora-bcat&source=pg, but I don't directly control the server
and didn't write the web page, so I don't have a reduced test case.

When you reload the page (with or without forcing a reload with SHIFT),
Firefox uses cached responses for the XHR requests, even though the
server doesn't send cache-related headers in the first reply.

Firefox 49 and Chrome don't always use cached responses (calixte tried on Aurora
and it was the same), Nightly does.

Some observations:
- In about:cache, one of the cached files ('notification.txt') has
  a very short expiration in 49 (a few seconds), a very long one in
  Nightly (one week).
- If I load the resource directly in a separate tab, everything starts
  working as expected.

Here's an example of the cached request/response:
Host: crash-analysis.mozilla.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: */*
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxaurora-bcat&source=pg
DNT: 1
Connection: keep-alive


Accept-Ranges: bytes
Content-Length: 0
Content-Type: text/plain
Date: Wed, 28 Sep 2016 12:57:36 GMT
Etag: "5699a4f8-0"
Last-Modified: Sat, 16 Jan 2016 02:03:36 GMT
Server: nginx/1.6.3
This report is no very detailed, still I think we can fairly easily immediately close it.

> - In about:cache, one of the cached files ('notification.txt') has
>   a very short expiration in 49 (a few seconds), a very long one in
>   Nightly (one week).

Please ignore this.  It's not clear when this file has been modified and attempted to load exactly w/o a cached entry.  I strongly believe it's just misinterpretation from :marco.

(In reply to Marco Castelluccio [:marco] from comment #0)
> When you reload the page (with or without forcing a reload with SHIFT),
> Firefox uses cached responses for the XHR requests, even though the
> server doesn't send cache-related headers in the first reply.

What I understand from an IRC debate preceding filing of this bug, some XHR responses are simply reused w/o revalidation.  It's perfectly OK.  This depends on Last-Modifed and Date response headers and how we calculate the heuristic freshness lifetime.  The server doesn't send Cache-control: no-cache.  In that case we don't do revalidation unless the freshness time expires.

There was no change in this logic between m-c and m-a.  

When I copy my cache2 dir to a profile that I then run in aurora, I get the same result.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
Only problem that might be a concern here is that even Ctrl-F5 doesn't force revalidation.  I believe we've had a bug for this and it has been fixed (load flags not propagating to xhr sub-resource loads.)  Anyway, 48, 49, 51 all behave the same way.
(In reply to Honza Bambas (:mayhemer) from comment #2)
> Only problem that might be a concern here is that even Ctrl-F5 doesn't force
> revalidation.  I believe we've had a bug for this and it has been fixed
> (load flags not propagating to xhr sub-resource loads.) 

its not clear to me that it should (or should not).. if the page is alive for 4 hours doing xhr things after being reloaded, when does the xhr stop taking on xhr semantics?
(In reply to Patrick McManus [:mcmanus] from comment #3)
> (In reply to Honza Bambas (:mayhemer) from comment #2)
> > Only problem that might be a concern here is that even Ctrl-F5 doesn't force
> > revalidation.  I believe we've had a bug for this and it has been fixed
> > (load flags not propagating to xhr sub-resource loads.) 
> 
> its not clear to me that it should (or should not).. if the page is alive
> for 4 hours doing xhr things after being reloaded, when does the xhr stop
> taking on xhr semantics?

Hmm.. I may recall the bug now.  It was about propagating load flags down by the iframe tree.  Not to deliver it to xhr.
You need to log in before you can comment on or make changes to this bug.