Proposal : add an attribute to hint the server which headers to copy in push requests

Hi there,

I opened a Pull Request proposing to add a new attribute to the `Link
rel=preload` HTTP header: https://github.com/w3c/preload/pull/149

Here is the rationale (copied from the description of the PR):

HTTP/2 Server Push is more and more for web APIs as an alternative to
GraphQL and compound documents. Mechanisms such as the ones described in
Internet-Drafts such as Vulcain <https://github.com/dunglas/vulcain> (I'm
the author) or "HTTP-client suggested Push Preference"
<https://tools.ietf.org/html/draft-pot-prefer-push-01> allow clients to
request the server to push relations of the main resource that will be
needed by the client. Some API frameworks also allow to use HTTP/2 Server
Push instead of compound documents
<https://api-platform.com/docs/core/push-relations/>.

While technologies such as Node.js, Go and Java allow to directly trigger
HTTP/2 Server Pushes (and can the easily implement such mechanisms), many
others including PHP and CGI haven't access to the TCP (or UDP) connection
and depend of the web server to trigger pushes. To do so they use this
specification and set Link rel=preload headers.

Even when using technologies able to trigger true HTTP/2 Server Pushes,
it's very common for production applications to sit behind reverse proxies
such as Nginx or Apache, and/or optimization proxies such as CloudFlare or
Fastly.
Most proxies use HTTP 1.1 to connect to the upstream server. Even the few
(such as Caddy and Apache) supporting HTTP/2 or H2C don't support (yet)
proxying HTTP/2 Server Pushes. So even in these cases, Link rel=preload
headers are used to trigger the pushes.

Currently, as very well explained in Apache's documentation
<https://httpd.apache.org/docs/2.4/en/howto/http2.html#push>, most proxies
copy only a few "safe" headers from the explicit request to Push requests.

This is a big limitation for HTTP APIs (among other use cases): most of
them require authorization (via cookies or the Authorization header),
content negotiation, and/or custom headers (for instance the Preload,
Fields or Prefer-Push headers defined in the previously mentioned
Internet-Drafts) for more details. See the following Nginx issues: #1817
<https://trac.nginx.org/nginx/ticket/1817>, #1851
<https://trac.nginx.org/nginx/ticket/1851>, #1935
<https://trac.nginx.org/nginx/ticket/1935>.

A few proxies (such as Caddy v1 <https://caddyserver.com/v1/docs/push>)
allow to configure which headers to pass as a workaround. But having to add
such configuration for every path requiring to pass extra headers isn't
very straightforward.

In this PR, I propose to add a new attribute to this specification allowing
the developer to indicate to the server which headers to copy. This
approach allows the developer to configure headers to copy on a per
resource basis (and/or any other criteria at the sole discretion of the
app). The application can dynamically indicate which headers to copy (and
so implement its own security policy) without requiring specific
configuration in the web server.

Examples:

Copy a few headers:

Preload: </resource>; rel=preload; as=fetch; pushheaders="Cookie,
Accept-Language"

Copy all headers:

Preload: </resource>; rel=preload; as=fetch; pushheaders="*"

The proposed syntax is similar to the one of Access-Control-Allow-Headers
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers>
.

What do you think about this proposal?
Best regards,
-- 
Kévin Dunglas

https://dunglas.fr / @dunglas <https://twitter.com/dunglas>