Allow custom HTTP headers to be defined for a preload request

[yoavweiss]

Continuation of w3c/preload#157

[jimmydief]

Please correct me if I'm wrong but this seems especially crucial with planned browser changes to block third-party cookies. Many apps which are embedded in third-party contexts will likely deal with the third-party cookie changes by switching to HTTP headers for authentication. As a result, those apps will lose the ability to preload critical fetch resources which require authentication.

[nate-at-gusto]

I can't "thumbsup" the archived repo, so I'd like to reiterate this comment about using the type attribute to set Accept. It would certainly work for my use-case, though I can see how this would be a potentially breaking change.

[yoavweiss]

In general for preloads, the as attribute would mean the browser uses the Accept header typically used for the related destination. That won't help you create an Accept: application/json request header though.

[nate-at-gusto]

If I'm reading Noam's comment here: https://bugs.chromium.org/p/chromium/issues/detail?id=1072144#c18 correctly, I think the underlying issue ("accept header causing preload not be accepted") is resolved?

[zcorpan]

If I understand correctly, the change removed checking of the Accept header when matching the cached entry. So, it makes the error go away, but doesn't let you do content negotiation when preloading.

[mitar]

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=1415291