New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 740568 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Leaves the project on 2018/03/02
Closed: Jul 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Preload headers for fonts break when using type attribute

Reported by daly...@gmail.com, Jul 10 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Example URL:
https://robert-daly.com/temp/font/?spec=true

Steps to reproduce the problem:
1. Open network panel and look at document Link headers
2. https://robert-daly.com/temp/font/ will preload font from header
3. https://robert-daly.com/temp/font/?spec=true will console warning and not load font

What is the expected behavior?
https://robert-daly.com/temp/font/?spec=true is from the W3 spec which specifies font type in the headers and does not work.

https://www.w3.org/TR/preload/#x2.link-type-preload#a.3-developer,-server,-and-proxy-initiated-fetching

What went wrong?
Chrome doesn't seem to follow the spec when it comes to type.

Did this work before? No 

Chrome version: 59.0.3071.115  Channel: canary
OS Version: OS X 10.12.4
Flash Version:
 

Comment 1 by mmenke@chromium.org, Jul 10 2017

Components: -Internals>Network Blink>Network
Labels: Needs-Triage-M59
Components: -Blink>Network Blink>Loader
Status: WontFix (was: Unconfirmed)
Looks this is because we use STRICT_QUOTES in link_header_util.cc. It makes the parser to accept quoted parameters only when they're quoted with the double-quote character.

According to https://tools.ietf.org/html/rfc5988, Chromium is working as intended.

I've filed a spec bug against the preload spec
https://github.com/w3c/preload/issues/106
Owner: tyoshino@chromium.org

Sign in to add a comment