W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: PUSH_PROMISE and load balancers

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 26 Sep 2014 07:54:51 +0100
Message-ID: <CABkgnnUQNi+a82-BErVcOagO=XbYRsC+s4q_rg8S3EKsfUtXug@mail.gmail.com>
To: Stuart Douglas <stuart.w.douglas@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
The easiest solution is to use two connections: one for push-enabled
clients, and one for those without push support (including HTTP/1.1
clients as well as clients that disable push).

The SETTINGS_ENABLE_PUSH flag can be different on each connection.

On 26 September 2014 01:33, Stuart Douglas <stuart.w.douglas@gmail.com> wrote:
> So I have been thinking about the case where you have a HTTP2 aware load
> balancer that serves both HTTP1 and HTTP2 clients, and uses HTTP2 to connect
> to the backend servers.
> Such load balancers will generally maintain a connection pool to the backend
> servers, and to allow PUSH_PROMISE to be used will need to enable push on
> the connection.
> I am thinking about then case when a HTTP1 client connects to this proxy,
> the backend servers will attempt to use PUSH_PROMISE to push content to the
> server, even though the load balancer knows in advance that it cannot accept
> the content.
> It would be possible to hack around this to some extent (e.g. using a custom
> header to signify that push should be disabled for this request), however I
> was thinking that a much nicer solution would be to add a flag to the
> HEADERS frame indicating that push should be disabled for this request only
> (i.e. no PUSH_PROMISE frame should be sent with this request as the
> associated stream id).
> Note that you can't really just send a SETTINGS frame before each request to
> alter the SETTINGS_ENABLE_PUSH flag. This will work for the simple case if
> you are allocating one connection per request, however it won't work if the
> proxy is multiplexing requests from different clients over the same HTTP2
> connection.
> Thoughts?
> Stuart
Received on Friday, 26 September 2014 06:55:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC