Re: [quicwg/base-drafts] Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3309)

[Ryan Hamilton <[e-mail]>]

RyanAtGoogle commented on this pull request.



> @@ -1238,9 +1232,20 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 PUSH_PROMISE frame that contains a larger Push ID than the client has advertised
 as a connection error of H3_ID_ERROR.
 
-A server MUST NOT use the same Push ID in multiple PUSH_PROMISE frames. A client
-MUST treat receipt of a Push ID which has already been promised as a connection
-error of type H3_ID_ERROR.
+A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the
+decompressed request header sets MUST contain the same fields in the same
+order, and both the name and and value in each field MUST be exact
+matches. If a client receives a Push ID that has already been promised
+and detects a mismatch, it MUST respond with a connection error of type
+H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the
+client MUST ignore the duplicate PUSH_PROMISE frame.

Hm. I think there is a difference in philosophy here. 

> HTTP/2 associates each push with the (single) request where the server promised it. HTTP/3 allows a push to be associated with multiple requests.

Totally agree with this! If a client makes requests A and B, the server can promise to push resource C on both A and B. This is clearly true.

But at the HTTP/3 layer (not at the web browsing layer) there is no notion of navigation or of subsequent requests being "associated" with earlier HTTP/3 streams (on which a resource may have been promised). Or at least I don't think there is.

My understanding of the motivation for allowing multiple pushes in HTTP/3 is not because we want to allow multiple subsequent requests for the same resources to be associated with the same pushed stream. Instead it was because HTTP/2 is in-order and HTTP/3 is not. In HTTP/2 if a client requested A and B and the server knew that both referenced resource C, it could push C a single time and be confident that requests initiated by the reference to C in the bodies of A and B would both come *after* the promise of C. However in HTTP/3 this is not the case. Since the promise for C is delivered on the request stream there is no ordering guarantee that the push (on A) will arrive at the client before the body of B (which contains the reference to C) arrives. As such, if the server only wants to push C once, it needs to make sure both promises are know.

But this, to me, is orthogonal to the issue of associating multiple subsequent requests with the same push data down at the HTTP/3 layer because each of these requests are somehow associated with the original requests A and B.

Am I thinking about this the wrong way?

> Since Chrome can split navigations across connections, doesn't having the push cache at the connection level means you might miss that something was already pushed because it was promised on a different connection than Chrome was going to use for the request?

While Chrome does store pushes in a per-connection cache (which is really just the pushed streams themselves) it also has a "global" index of "promises by URL" which allows a request which would, by default, go on one connection to be satisfied by a promise from another connection (which might otherwise be going away, for example).


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309#discussion_r365429179