Subject: Server Push, Alt-Svc and connection switching

From: Lucas Pardue <[email-masked]>
Date: Wed, 16 Oct 2019 01:51:22 +0100

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

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 17 Oct 2019 09:12:32 -0700

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

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 17 Oct 2019 19:44:26 +0200 (CEST)

> of an h3 connection, the browser *should* still be able to find the h2 

If the client uses a "push cache", I think it makes sense for that cache to 
work across HTTP/2 and HTTP/3 since otherwise the upgrade itself risk wasting 
resources that were already pushed to the client. It would also otherwise risk 
the same thing if the client deems it needs to fallback to h2 after having 
received pushed resources over h3...

-- 

  / daniel.haxx.se