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

Thanks for the proposal! I answered
<https://github.com/w3c/preload/pull/149#issuecomment-665523861> on the PR.
Let's continue the discussion there :)

On Thu, Jul 9, 2020 at 5:01 PM Kévin Dunglas <kevin@dunglas.fr> wrote:

> 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>
>
>