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.

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

Interesting! I read the language in RFC7540 differently, I think. It says "Pushed responses are always associated with an explicit request from the client.  The PUSH_PROMISE frames sent by the server are sent on that explicit request's stream. " To me, this language exists to prevent unilateral pushes by the server. In other words, if there are no client-initiated requests outstanding, the server may not push any resources. 

But if I understand you correctly, you read it as enabling implementations to make use of this association for more than simply preventing unilateral pushes. (Presumably this association could be used by an implementation to "hide" the pushed resource from a subsequent request not associated with the original request, but to "show" it to a subsequent request that *was* associated with the original request? I would not have thought this was "a thing".) Fascinating.

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

This is a good question :) I think some editorial exposition on this front would be welcome! I would be very curious to hear what other folks think of this issue.

In any case, backing up to the change you proposed:

> client SHOULD associate the pushed content with each stream on which a PUSH_PROMISE was received.

I think I'm comfortable with this text even though I'm slightly uneasy about what "associate" means here. But that's pretty orthogonal to this PR since it existed in the DUPLICATE_PUSH language as well, so I'll go ahead and apply your suggestion.

Thanks for the great discussion!

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