Open Bug 1304912 Opened 4 years ago Updated 2 years ago
prefetch links do not advertise 304 on reload
Not sure if it's an issue with Firefox Devtools or if the information is not available at the Core. I created a test with two prefetch links. http://www.la-grange.net/2016/09/20/moz-prefetch/ First load all resources display a 200 OK. (normal) Hit reload button the prefetch links shows a 200 OK (not expected) again with a "cached" keyword (expected) and 0 B (expected) Should it advertise 304 instead? First request: 19:48:54 "GET /2016/09/20/moz-prefetch/ HTTP/1.1" 200 336 "-" 19:48:54 "GET /2016/09/20/moz-prefetch/normal.html HTTP/1.1" 200 985 "http://www.la-grange.net/2016/09/20/moz-prefetch/" 19:48:54 "GET /2016/09/20/moz-prefetch/private.html HTTP/1.1" 200 985 "http://www.la-grange.net/2016/09/20/moz-prefetch/" Second request: 19:49:01 "GET /2016/09/20/moz-prefetch/ HTTP/1.1" 304 - "-"
Opera Blink devtools show 304. The log in Comment #0 is on the server.
Cc'ing the right Product person.
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
Looking into it.
Ok you can take the bug.
Assignee: dd.mozilla → nobody
Status: ASSIGNED → NEW
Sorry for the confusion, please take the bug. I was just looking into this from the devtools product side of things.
(In reply to Bryan Clark (DevTools PM) [@clarkbw] from comment #5) > Sorry for the confusion, please take the bug. I was just looking into this > from the devtools product side of things. I do not know were the problem is. I took the bug to investigate, not to lose it. Have you found something? Do you know what is happening?
My feeling is that. At the first HTTP request, the browser fetches the links (which is normal because of rel="prefetch") But at the second HTTP request, there is no check to the server again (no conditional request), so the server never sends a 304 Not Modified, because there is no request. The resources are indeed in the cache. So somehow I would say that it's neither a 200 or a 304. I haven't checked if Blink/Opera and WebKit/Safari sends a conditional request. The behavior of prefetch links is described by https://w3c.github.io/resource-hints/#dfn-prefetch And the spec doesn't seem to say anything on HTTP reload of the initial resource. Maybe Ilya knows.
Different browsers have different behaviors for "reload" which, btw, is also hard to pin down because we disagree on what checks are performed when based on pull-to-refresh vs reload button vs url bar, etc. I have a feeling that's what we're observing here.. Hitting the reload button in Chrome triggers a revalidation, even though there is a valid resource available in HTTP cache, hence 304. I'm not sure what FF does... In other words I don't think this is prefetch specific. Try swapping prefetch for XHR and I'm guessing you'll see the same thing.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.