1304912 - prefetch links do not advertise 304 on reload

Status: RESOLVED INCOMPLETE

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

Description

[Karl Dubost💡 :karlcow]

Attachment: network-panel-prefetch-links.png

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 - "-"

Comment 1

[Karl Dubost💡 :karlcow]

Opera Blink devtools show 304.
The log in Comment #0 is on the server.

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Cc'ing the right Product person.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

Looking into it.

Comment 4

[Dragana Damjanovic [:dragana]]

Ok you can take the bug.

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

Sorry for the confusion, please take the bug.  I was just looking into this from the devtools product side of things.

Comment 6

[Dragana Damjanovic [:dragana]]

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

Comment 7

[Karl Dubost💡 :karlcow]

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.

Comment 8

[Ilya Grigorik]

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.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Sylvestre Ledru [:Sylvestre]]

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

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.