W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: Server Push, Alt-Svc and connection switching

From: Ryan Hamilton <rch@google.com>
Date: Thu, 17 Oct 2019 09:12:32 -0700
Message-ID: <CAJ_4DfTKLUs+e6PrNY8Rn0y6YayTVGYKG=kLdNBBKRmRHJX4BQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I think that the browser *should* be able to use the pushed resources
regardless of the connection that was used to push them. In your example,
even though the receipt of the alt-svc header might result in the creation
of an h3 connection, the browser *should* still be able to find the h2

That being said, I believe Chrome does not do this :)

On Tue, Oct 15, 2019 at 5:54 PM Lucas Pardue <lucaspardue.24.7@gmail.com>

> Based on some observations of how Chrome Canary discovers HTTP/3 and
> switches, I've begun wondering how the connection switching behaviour plays
> with the way user agents implement server push - particularly around the
> concept of "push caches" that may or may not be tied to a connection.
> To use an example consider a document (index.html) that contains some tags
> for script1.js, script2.js and script3.js. On first visit, the request
> might happen as so
> index.html - requested over TCP+TLS using HTTP/2. Contains Alt-Svc: h3-23
>    * script1.js - requested over QUIC and H3
>    * script2.js - requested over QUIC and H3
>    * script3.js - requested over QUIC and H3
> Now consider Server Push in this scenario; where requests for index.html
> trigger server push for script(1-3).js unconditionally.
> What do people think n the above case when the server sends PUSH_PROMISE,
> HEADERS and DATA for scripts on HTTP/2 before sending the HEADERS for
> index.html that contains the Alt-Svc.
> If pushed responses are held in a "push cache" tied to the H2 connection,
> is there a chance that this is blown away when you change to H3? Or do the
> requests for scripts resolve to the push cache and promote to the client
> cache proper? Or something totally different unique to each implementation.
> This seems like an undesirable side-effect of our current capabilities and
> deployment plans if it indeed an issue.
> Any thoughts from the group?
> Lucas
Received on Thursday, 17 October 2019 16:12:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC