Process Preload link headers

[noamr]

Preload links based on link headers, some of them on document creation,
and the rest (viewport-dependant ones) when response chunks start arriving.

This can be used as an infra for early-hints and other link types.

Conforms to the current common denominator of implementations.

See #4224
Closes w3c/preload#148

• At least two implementers are interested (and none opposed):
  • already implemented
• Tests are written and can be reviewed and commented upon at:
  • Test preload headers for different document types
  • Blocking keyword
• Implementation bugs are filed:
  • Chromium: Double load of link header in media doc
  • Gecko: Link headers ignored for video/image docs
    (See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )
/semantics.html ( diff )

[domenic]

Great stuff, yet again you tackle some major tech debt and give us hope for the future :). /cc @annevk as some of the header parsing stuff is making me feel out of my depth.

[domenic]

Very glad you found that RFC parser!

[bashi]

I'm excited to see this to be defined!

One question from the POV of Early Hints: I guess we may not be able to create a document when we process link headers in Early Hints since we wouldn't know the content type of the final response. How should we handle the case?

Here are options I came up with: (1) Delay processing link headers until we can create a document, (2) define the process link headers algorithm without the document parameter, replacing the parameter with some other parameters which can be obtained from both early hints responses and the final response, or navigationParams.

I think (1) wouldn't be a viable option since it effectively makes Early Hints preloads no sense. OTHO I'm not sure (2) can be realistic. There might be other options.

cc: @yutakahirano @yoavweiss

[noamr]

I'm excited to see this to be defined!

One question from the POV of Early Hints: I guess we may not be able to create a document when we process link headers in Early Hints since we wouldn't know the content type of the final response. How should we handle the case?

Here are options I came up with: (1) Delay processing link headers until we can create a document, (2) define the process link headers algorithm without the document parameter, replacing the parameter with some other parameters which can be obtained from both early hints responses and the final response, or navigationParams.

I think (1) wouldn't be a viable option since it effectively makes Early Hints preloads no sense. OTHO I'm not sure (2) can be realistic. There might be other options.

cc: @yutakahirano @yoavweiss
Thanks for the suggestions!

I started prototyping something along the lines of (2), the idea is that navigation params would hold a map of preloaded resources that the document will use as the initial map once it's created.

As you said, (1) is not an option because it beats the purpose of early hints being early...

[bashi]

Fantastic, thank you for the update!