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

From: Kazuho Oku <[email-masked]>
Date: Wed, 01 Jan 2020 17:17:32 -0800

kazuho commented on this pull request.

> -become available, or can initiate requests for discovered resources and cancel
-the requests if the requested resource is already being pushed. When a client
-receives a new push stream with an as-yet-unknown Push ID, both the associated
-client request and the pushed request headers are unknown.  The client can
-buffer the stream data in expectation of the matching PUSH_PROMISE. The client
-can use stream flow control (see section 4.1 of {{QUIC-TRANSPORT}}) to limit the
-amount of data a server may commit to the pushed stream.
+Due to reordering, push stream data can arrive before the corresponding
+PUSH_PROMISE frame.  When a client receives a new push stream with an
+as-yet-unknown Push ID, both the associated client request and the pushed
+request headers are unknown.  The client can buffer the stream data in
+expectation of the matching PUSH_PROMISE. The client can use stream flow control
+(see section 4.1 of {{QUIC-TRANSPORT}}) to limit the amount of data a server may
+commit to the pushed stream.
+
+If the same Push ID is promised on multiple request streams, the decompressed

I think we can remove this sentence now that it is incorporated into the paragraph starting at line 605.

Sorry for me not being explicit about the move when suggesting changes to that paragraph.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 01 Jan 2020 17:33:39 -0800

> @@ -1238,9 +1233,10 @@ 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 headers MUST be idential.  A client MUST treat receipt of a
+Push ID which has already been promised with different headers than the previous
+promise as a connection error of type H3_ID_ERROR.

> MUST-error requires that the client keep the request headers for the lifetime of the connection in case it ever sees that Push ID again.

As stated in https://github.com/quicwg/base-drafts/issues/3275#issuecomment-566379821, it is my understanding that an endpoint can determine if the PUSH_PROMISE refers to a new Push ID or a Push ID it already has received, and therefore my preference goes to stating "MUST error if there is a mismatch, or ignore the PUSH_PROMISE frame."

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 06 Jan 2020 09:36:30 -0800

LPardue commented on this pull request.

agree with Kazuho but also that the the sentence should use Mike's suggestion of comparison rather than "byte-for-byte"

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 06 Jan 2020 09:47:17 -0800

```suggestion
decompressed request headers MUST be identical.  A client MUST treat receipt of a
```

maybe a x-ref to the definition of identical would help too

No comment about the MUSTiness but H3_ID_ERROR is not appropriate for this error condition IMO. Nor is it a frame error because all the syntax was correct. The closest comparison is malformed request, which elicits a H3_GENERAL_PROTOCOL_ERROR. Alternatively connection-level H3_REQUEST_REJECTED could fit but might need some other changes in the wider document to make sure this case is accommodated for.

-- 
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#pullrequestreview-338785962

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Jan 2020 10:22:11 -0800

@RyanAtGoogle pushed 1 commit.

1ff22b7f577fefa5d5062479a53354e032aee584  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/d7668a54c20039ccfd6dc7132e55c0f0ffc87047..1ff22b7f577fefa5d5062479a53354e032aee584

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Jan 2020 10:24:35 -0800

95c38f43b2f7f2cb36423b54fe533b9427007ee4  Update "identical" definition

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/1ff22b7f577fefa5d5062479a53354e032aee584..95c38f43b2f7f2cb36423b54fe533b9427007ee4

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Jan 2020 10:24:47 -0800

RyanAtGoogle commented on this pull request.

I've updated the text to use the "MUST error if mismatch detected" language.

> @@ -603,11 +602,11 @@ client making the indicated request.  This trades off network usage against a
 potential latency gain.  HTTP/3 server push is similar to what is described in
 HTTP/2 {{!HTTP2}}, but uses different mechanisms.
 
-Each server push is identified by a unique Push ID. This Push ID is used in a
-single PUSH_PROMISE frame (see {{frame-push-promise}}) which carries the request
-headers, possibly included in one or more DUPLICATE_PUSH frames (see
-{{frame-duplicate-push}}), then included with the push stream which ultimately
-fulfills those promises.
+Each server push is identified by a unique Push ID. This Push ID is used in one
+or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request
+headers, then included with the push stream which ultimately fulfills those
+promises. When the same Push ID is promised on multiple request streams, the
+decompressed request header fields MUST be byte-for-byte identical.

Done.

Done.

Modified to include the same language as on line 605. Hope this helps!

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 06 Jan 2020 10:31:08 -0800

> @@ -603,11 +602,13 @@ client making the indicated request.  This trades off network usage against a
 
+decompressed request header set MUST contains the same set of fields in the
+same order, and in each field both the name and and value MUST be byte-for-byte

```suggestion
same order, and in each field both the name and value MUST be byte-for-byte
```

> @@ -603,11 +602,13 @@ client making the indicated request.  This trades off network usage against a
 
+decompressed request header set MUST contains the same set of fields in the

```suggestion
decompressed request header set MUST contain the same set of fields in the
```

-- 
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#pullrequestreview-338812940

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Jan 2020 10:54:03 -0800

334869e1c6e7daf0378b18cf90527d5ea1ee7289  Apply suggestions from code review from Lucas

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/95c38f43b2f7f2cb36423b54fe533b9427007ee4..334869e1c6e7daf0378b18cf90527d5ea1ee7289

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Jan 2020 11:52:57 -0800

@MikeBishop how does this look now?

-- 
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#issuecomment-571287873

---

From: Mike Bishop <[email-masked]>
Date: Tue, 07 Jan 2020 18:31:11 +0000 (UTC)

MikeBishop approved this pull request.

-- 
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#pullrequestreview-339422699

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Jan 2020 17:28:11 -0800

kazuho approved this pull request.

-- 
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#pullrequestreview-339604708

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 07 Jan 2020 21:16:25 -0800

janaiyengar approved this pull request.

LGTM, but a few editorial suggestions.

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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 set MUST contain the same set of fields in the same
+order, and in each field both the name and and value MUST be byte-for-byte
+matches. When a client receives a Push ID which has alread been promised, if the

```suggestion
matches. If a client receives a Push ID that has already been promised
```

> @@ -379,10 +379,9 @@ An HTTP message (request or response) consists of:
 3. optionally, trailing headers, if present (see {{!RFC7230}}, Section 4.1.2),
    sent as a single HEADERS frame.
 
-A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) or
-DUPLICATE_PUSH (see {{frame-duplicate-push}}) frames before, after, or
-interleaved with the frames of a response message. These PUSH_PROMISE and
-DUPLICATE_PUSH frames are not part of the response; see {{server-push}} for
+A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) frames

```suggestion
A server MAY send one or more PUSH_PROMISE frames (see {{frame-push-promise}})
```

+decompressed request header set MUST contain the same set of fields in the

```suggestion
decompressed request header sets MUST contain the same fields in the
```

+decompressed request header set MUST contain the same set of fields in the
+same order, and in each field both the name and value MUST be byte-for-byte

```suggestion
same order, and both the name and the value in each field MUST be exact
```

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
+decompressed request header set MUST contain the same set of fields in the same

```suggestion
decompressed request header sets MUST contain the same fields in the same
```

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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 set MUST contain the same set of fields in the same
+order, and in each field both the name and and value MUST be byte-for-byte

```suggestion
order, and both the name and and value in each field MUST be exact
```

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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 set MUST contain the same set of fields in the same
+order, and in each field both the name and and value MUST be byte-for-byte
+matches. When a client receives a Push ID which has alread been promised, if the
+client detects a mismatch, it MUST response with a connection error of type

```suggestion
and detects a mismatch, it MUST respond with a connection error of type
```

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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 set MUST contain the same set of fields in the same
+order, and in each field both the name and and value MUST be byte-for-byte
+matches. When a client receives a Push ID which has alread been promised, if the
+client detects a mismatch, it MUST response with a connection error of type
+H3_GENERAL_PROTOCOL_ERROR. Otherwise it MUST ignore the PUSH_PROMISE frame if no

```suggestion
H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the
client MUST ignore the duplicate PUSH_PROMISE frame.
```

> @@ -1238,9 +1232,13 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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 set MUST contain the same set of fields in the same
+order, and in each field both the name and and value MUST be byte-for-byte
+matches. When a client receives a Push ID which has alread been promised, if the
+client detects a mismatch, it MUST response with a connection error of type
+H3_GENERAL_PROTOCOL_ERROR. Otherwise it MUST ignore the PUSH_PROMISE frame if no
+mismatch is detected.

```suggestion
```

-- 
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#pullrequestreview-339646724

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 08 Jan 2020 06:45:36 -0800

ff8e28d2285de11780e8d9659540097e983c3578  Apply suggestions from Janacode review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/334869e1c6e7daf0378b18cf90527d5ea1ee7289..ff8e28d2285de11780e8d9659540097e983c3578

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 08 Jan 2020 07:45:59 -0800

This is looking good now. However, the deletion of the DUPLICATE_PUSH prose removes some of the description of why a server might choose to do this. 

I think we should incorporate some of that text, or go look further back to how the PUSH_PROMISE section was written before DUPLICATE_PUSH - https://tools.ietf.org/html/draft-ietf-quic-http-16#section-4.2.6

For example

```
   Allowing duplicate references to the same Push ID is primarily to
   reduce duplication caused by concurrent requests.  A server SHOULD
   avoid reusing a Push ID over a long period.  Clients are likely to
   consume server push responses and not retain them for reuse over
   time.  Clients that see a PUSH_PROMISE that uses a Push ID that they
   have since consumed and discarded are forced to ignore the
   PUSH_PROMISE.
```

-- 
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#issuecomment-572128822

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 09 Jan 2020 13:50:13 -0800

facfb784442e61749e46cf8bec58ad3de4340617  Add motivation for duplicate push ids

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/ff8e28d2285de11780e8d9659540097e983c3578..facfb784442e61749e46cf8bec58ad3de4340617

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 09 Jan 2020 13:51:49 -0800

> I think we should incorporate some of that text, or go look further back to how the PUSH_PROMISE section was written before DUPLICATE_PUSH - https://tools.ietf.org/html/draft-ietf-quic-http-16#sect…

Good point. Done.

-- 
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#issuecomment-572773063

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Jan 2020 07:42:33 -0800

MikeBishop commented on this pull request.

I don't think we have to talk about discarding necessarily, but encouraging comparison would be good.

> @@ -623,31 +624,25 @@ allows the server push to be associated with a client request.  Promised
 requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}.
 
 The same server push can be associated with additional client requests using a
-DUPLICATE_PUSH frame (see {{frame-duplicate-push}}).
+PUSH_PROMISE frame with the same Push ID on multiple request stream.

```suggestion
PUSH_PROMISE frame with the same Push ID on multiple request streams.
```

> @@ -1238,9 +1232,20 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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.

```suggestion
client SHOULD associate the pushed content with each stream on which a PUSH_PROMISE was received.
```
I don't think "MUST ignore" is what we want.  It's not an error case, it's a client optimization.

> @@ -1238,9 +1232,20 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 
-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

```suggestion
matches. Clients SHOULD compare the request header sets for resources promised
multiple times. If a client receives a Push ID that has already been promised
```
I don't know that we need to be explicit about the discard, but I think we should encourage comparison.

-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.
+
+Allowing duplicate references to the same Push ID is primarily to reduce
+duplication caused by concurrent requests.  A server SHOULD avoid reusing a Push
+ID over a long period.  Clients are likely to consume server push responses and
+not retain them for reuse over time.  Clients that see a PUSH_PROMISE that uses
+a Push ID that they have since consumed and discarded are forced to ignore the

```suggestion
a Push ID that they have already consumed and discarded are forced to ignore the
```

-- 
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#pullrequestreview-341242542

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Jan 2020 10:13:02 -0800

86067c7e7a9b33ac04eb28436e8ae772e2740c60  Apply suggestions from mbishop code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/facfb784442e61749e46cf8bec58ad3de4340617..86067c7e7a9b33ac04eb28436e8ae772e2740c60

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Jan 2020 10:16:15 -0800

Hm. I agree that it's an error, but I'm not sure what it means to associate pushed content with the request stream that received the PUSH_PROMISE. There is only going to be a single push stream with the specified push id, of course. And as such, only a single request can be directly associated with that push stream. Of course, because of caching, other requests can be satisfied by the cached response. But that's at a layer above the streams, right?

(in chrome, I don't think we have any mapping between pushed streams and the request stream that promised the pushes so maybe we're "doing it wrong"?)

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Jan 2020 12:42:37 -0800

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.

> There is only going to be a single push stream with the specified push id, of course. **And as such, only a single request can be directly associated with that push stream.**

This is the difference -- one need not follow from the other.  HTTP/3 allows a response to be promised on multiple streams, implying that you'll potentially want it as a dependency for each of those things.  That means it's intended to be possible for that push to satisfy several client requests (from different tabs, or threads, or iframes, or whatever).

Now, if the response is cacheable, you're right -- the HTTP cache will probably satisfy those other requests and it doesn't have to reach the push cache.  But the pushed response need not be cacheable; it can nonetheless be used multiple times if promised multiple times.

In WinInet, we had a concept of a navigation that was passed down from the browser, and the push cache was at the navigation level rather than the connection level.  It was part of whichever navigation included the stream that received the promise.  Hypothetically, if something were promised on several streams from different navigations, HTTP/3 would enable putting that response in both navigations' push caches.

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?

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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Jan 2020 13:03:21 -0800

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 diff…

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 10 Jan 2020 13:16:23 -0800

> -immediately available.  The client can either delay generating new requests for
-content referenced following the DUPLICATE_PUSH frame until the request headers

Improvement suggestion: we actually have better guidance on the specific way to do flow control for the push streams in https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-6.2, so a link to that would be more useful that to QUIC Transport IMO.

-- 
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#pullrequestreview-341426308

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Jan 2020 13:28:41 -0800

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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Jan 2020 15:03:23 -0800

> 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 thi…

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.

> 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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Jan 2020 15:03:42 -0800

833a897a739402b7672ce0683877c65ae9598612  Update draft-ietf-quic-http.md per mbishop

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3309/files/86067c7e7a9b33ac04eb28436e8ae772e2740c60..833a897a739402b7672ce0683877c65ae9598612

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Jan 2020 08:49:06 -0800

-- 
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#pullrequestreview-341985606