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

Thanks for the proposal! I answered
<> on the PR.
Let's continue the discussion there :)

On Thu, Jul 9, 2020 at 5:01 PM Kévin Dunglas <> wrote:

> Hi there,
> I opened a Pull Request proposing to add a new attribute to the `Link
> rel=preload` HTTP header:
> 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 <> (I'm
> the author) or "HTTP-client suggested Push Preference"
> <> 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
> <>.
> 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
> <>, 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
> <>, #1851
> <>, #1935
> <>.
> A few proxies (such as Caddy v1 <>)
> 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
> <>
> .
> What do you think about this proposal?
> Best regards,
> --
> Kévin Dunglas
> / @dunglas <>

Received on Wednesday, 29 July 2020 08:40:23 UTC