- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Wed, 16 Oct 2019 01:51:22 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CALGR9oY_zT0rnoh2TdrfsxNjhx2uNv3y21Mqmt9DPQ8CPdpx+Q@mail.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 Wednesday, 16 October 2019 00:51:36 UTC