CSS preload scanner should support Referrer-Policy
Reported by
coffeebu...@gmail.com,
Jun 4 2018
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36 Steps to reproduce the problem: 1. Load the attached 'index.html' sample page. You don't need any of the referenced stylesheets, as a 404 is still able to demonstrate the issue. 2. Reload the page with Developer Tools on the network tab. 3. Look at the request headers for each stylesheet. What is the expected behavior? Consistent "Referer" header for all requests. What went wrong? By default, any css @import does not have the Referer header set. If a css @import specifies a media query (e.g. "print"), then that import and all subsequent imports have the Referer header set. In the case of my example index.html, this means imports 1&2 do not have Referer set, while 3&4 have Referer set. Workaround is to use "<link..." tags instead of css import. Did this work before? N/A Chrome version: 67.0.3396.62 Channel: stable OS Version: 10.0 Flash Version: Options when I opened a ticket were API, Javascript, or Developer Tools, but I'm not sure which is the best fit.
,
Jun 5 2018
,
Jun 5 2018
Unable to reproduce the issue on Win-10 using chrome reported version #67.0.3396.62 and latest canary #69.0.3449.2. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Opened the attached file "index.html" 2. Reloaded the page with Developer Tools on the network tab. 3. Looked at the request headers for each stylesheet. 4. Observed consistent "Referer" header for all requests as expecte coffeeburrito@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest canary #69.0.3449.2 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Jun 5 2018
Sorry, I forgot that viewing html files directly from disk had that effect on headers. Step 0. Put the file on a web server. I tested with IIS and Ubuntu/Apache 2.4. The attached screen cast is using a fresh Canary profile.
,
Jun 5 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 7 2018
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.62 and latest canary #69.0.3451.0. This is a non-regression issue as it is observed from M60 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Jun 7 2018
,
Jun 8 2018
Loading triager here.
Interesting.
This occurs if an inline <style> element with @import is written in HTML.
Referrer is set when (according to DevTools):
The <style> element is dynamically inserted:
var s = document.createElement('style');
s.innerText = `
@import url("./style1.css");
@import url("./style2.css");
@import url("./style3.css");
@import url("./style4.css");`;
document.body.appendChild(s);
Or @import is in an external CSS:
<link rel=stylesheet href="test.css"></link>
test.css:
@import url("./style1.css");
@import url("./style2.css");
@import url("./style3.css") screen;
@import url("./style4.css");
,
Jun 8 2018
This seems to be an issue of CSSPreloadScanner. [SubIssue A] CSSPreloadScanner initiates preloading requests foor style1.css and style2.css without Referrer. Lack of referrer seems to be a bug in CSSPreloadScanner. [SubIssue B] CSSPreloadScanner don't support media rules, and stops processing the CSS when encountered "screen" for style3.css, and therefore preloading requests are not initiated for style3.css and style4.css. Instead, I suspect non-preloading requests are initiated somewhere in <style>/CSS code, and at this time referrer is correctly set. (More precisely, CSSPreloadScanner's state goes back to kInitial when it encountered "s" in "screen" here: https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/core/html/parser/css_preload_scanner.cc?sq=package:chromium&dr=CSs&g=0&l=180 but immediately after that the state becomes kDoneParsingImportRules: https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/core/html/parser/css_preload_scanner.cc?sq=package:chromium&dr=CSs&g=0&l=115 at "c" in "screen".) This is why referrer is set for style3.css and style4.css, but this is a separate issue from [SubIssue A]. In all cases the non-preloading requests with referrer set are dispatched, but merged by ResourceFetcher into the preloading requests if there any, even Referrer header is different. +csharrison@, could you triage this issue?
,
Jun 8 2018
This behavior came from jochen: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/YkXg6ZkW2Bs/6aDLAs0qBwAJ https://codereview.chromium.org/2780533002 We should support Referrer-Policy for css preload scanner. I'm not sure I'll be able to get to it, so marking as Available.
,
Jun 11 2018
hum, so Referrer-Policy as in the response header is supported by the CSS preload scanner, it just looks like it's not sending the correct outgoing Referrer header, right?
,
Jun 11 2018
I think what's broken is the fact that: 1. CSS preloads are set to use base URL as referrer (I don't know why exactly this is the case) 2. The base URL in the preload scanner code starts as empty, and is only updated when we have a <base> tag. I'm not exactly sure what the desired behavior is, but there is no referrer because (2) is empty. Maybe this isn't exactly Referrer-Policy related. (as in, conforming to the doc's Referrer-Policy). A workaround in this case would be to include a <base> tag before the @imports until this is fixed. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by gov...@chromium.org
, Jun 4 2018Labels: Needs-Triage-M67