Prefetch request not sending same "Accept" header as normal request
Reported by
tobias.m...@mercadolibre.com,
Jul 6 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Prefetch some page with <link rel="prefetch" href="http://www.somepage.com"> 2. Go to that webpage ("http://www.somepage.com"). What is the expected behavior? Both requests should use the same "Accept" header. What went wrong? The prefetch request sends: Accept: */* Meanwhile, the normal request sends: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Doing it this way, the prefetched page doesn't know it can use webp images. Did this work before? N/A Chrome version: 51.0.2704.103 Channel: n/a OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 22.0 r0
,
Jul 14 2016
Network bug triager here. Changing component to Blink->Loader as I think prefetching falls under that.
,
Jul 14 2016
I'm not sure this is a blink issue: https://cs.chromium.org/chromium/src/content/browser/loader/mime_type_resource_handler.cc?rcl=1468509561&l=158
,
Jul 14 2016
Assigning to japhet@ for now due to this relatively recent change in this area of code: https://codereview.chromium.org/1839473002 Not clear to me if this is actually a bug or not, as I'm not super familiar with rel=prefetch semantics. (+cc igrigorik for that reason).
,
Jul 29 2016
I'm kind of inclined to say that this is working as intended, but I'd prefer igrigorik's opinion to be certain. prefetch doesn't appear to have any indicator of the expected resource type, so there's not much we can do besides Accept: */*. I would think it makes sense to then provide a more precise Accept header once we know that we're expecting a main resource. igrigorik, thoughts?
,
Aug 22 2016
Sorry, missed this earlier... > prefetch doesn't appear to have any indicator of the expected resource type, so there's not much we can do besides Accept: */*. I would think it makes sense to then provide a more precise Accept header once we know that we're expecting a main resource. Expected resource type doesn't really matter as I could return a WebP for an image response; a CSS file with WebP references; A JS file with...; an HTML file with... As such, we should advertise the same Accept string as when initiating a new navigation / user typing in a URL in the the address bar and hitting enter. Also, we should make sure that rel=preload does as well.
,
Aug 22 2016
Ok, just to verify, the standard accept header we send for main frame navigations is currently: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 That's what you'd recommend?
,
Aug 22 2016
Yep.
,
Sep 17 2016
I have a use case where this seems to trigger an additional download (see attached screenshot) so the same resource is fetched three times. One of the meta tags of the page asks the browser to download a resource via prefetch, and the source of the page references the same resource. However, one is requested with accept/webp (and served as such) while the other is not. This is what has already been described here. The browser seems to be triggering twice the non-prefetch resource in the Network tab. This was tested with Version 55.0.2863.0 canary (64-bit) on OS X 10.11.6 (15G1004) and the website is www.instantluxe.com (you can send DNT headers to avoid tracking).
,
Sep 18 2016
Comment #9 indicates a different issue than the original one. Could you please open a separate tracking bug?
,
Sep 24 2016
In answer to Comment #10: Sure, I'll do that after this issue has been fixed and I can reproduce again, and I'll attach a network-internals. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by asanka@chromium.org
, Jul 8 2016Labels: -OS-Mac OS-All
Status: Untriaged (was: Unconfirmed)