Open Bug 1304912 Opened 4 years ago Updated 2 years ago

prefetch links do not advertise 304 on reload

Categories

(Core :: Networking: HTTP, defect, P3)

48 Branch
defect

Tracking

()

People

(Reporter: karlcow, Unassigned, NeedInfo)

References

()

Details

(Whiteboard: [necko-next])

Attachments

(1 file)

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.
Whiteboard: [necko-next]
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.
Flags: needinfo?(dd.mozilla)
(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?
Flags: needinfo?(dd.mozilla)
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.
Flags: needinfo?(igrigorik)
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.