Re: Server Push, Alt-Svc and connection switching

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

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

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