[PATCH] HTTP/2: expose function to push single resource to modules
Ruslan Ermilov
ru at nginx.com
Fri Feb 9 07:35:59 UTC 2018
On Thu, Feb 08, 2018 at 07:48:25PM +0000, Alessandro Ghedini wrote:
> On Thu, Feb 08, 2018 at 10:00:27PM +0300, Maxim Dounin wrote:
> > On Thu, Feb 08, 2018 at 04:52:59PM +0000, Alessandro Ghedini wrote:
> >
> > > # HG changeset patch
> > > # User Alessandro Ghedini <alessandro at ghedini.me>
> > > # Date 1518108716 0
> > > # Thu Feb 08 16:51:56 2018 +0000
> > > # Branch expose-push
> > > # Node ID 1bb98b06d5536dfc80a407aabd8d06f9309f8df6
> > > # Parent a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > > HTTP/2: expose function to push single resource to modules.
> > >
> > > This makes it possible for 3rd party modules to implement alternative
> > > methods for deciding which resources to push to clients on a per-request
> > > basis (e.g. by parsing HTML from the response body, by using a custom
> > > Link header parser, ...).
> > >
> > > No functional changes.
> >
> > Not sure this is a good idea.
> >
> > You may consider exposing a variable to be used in http2_push
> > instead.
>
> Right, the problem is that as far as I can tell http2_push only supports a
> single resource, even when a variable is used, so it wouldn't be possible to
> push multiple resources without specifying multiple http2_push directives,
> each with its own variable, and even then you'd only have a fixed number of
> resources that can be pushed, which wouldn't work well when the number of
> resources changes depending on each request/response.
>
> So in the end exposing the internal functions to modules seemed better than
> just trying to make http2_push support multiple resources per directive,
> which would add complexity to NGINX itself rather than the external modules
> (though I can do that if you think it would be a better solution).
We've also considered adding support for the X-Accel-Push header, but
decided not to implement it at this time. If implemented, there could
be multiple X-Accel-Push headers in the proxied response.
More information about the nginx-devel
mailing list