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

[Mike Bishop <[e-mail]>]

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

Yes, I think we've found a conceptual difference.  You're looking at the promise purely as a way to forestall requests for that resource, and the fact that it happens to be on a given stream is only because the server thinks there might be something on that stream where you need to know about the push first.  But handling of push in Chrome is global -- if you request A and B, I promise X on A, and B references X, you'll use the pushed object if you know about it.  I agree, in this implementation style, the first PUSH_PROMISE frame to arrive carries all the information you need, and any subsequent ones are basically irrelevant.

But RFC7540 says that "Pushed responses are always associated with an explicit request from the client."  How (or whether, obviously!) that association is used is implementation-dependent, but I think for consistency's sake we need to provide that association in the document.  (As far as I know, the only thing H2 explicitly used this association for internally was for prioritization -- pushed streams depend on the associated stream.)

Do we need a separate editorial issue to expand on this a bit in the document, or is it there and we're just reading through different filters?

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