Subject: For review: editorial updates pull request

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 16:52:26 -0700

Another, fairly significant pull request with some suggested spec
edits. Please review carefully, these are a bit more extensive than
what I submitted yesterday...

https://github.com/http2/http2-spec/pull/81

- James

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Apr 2013 22:13:50 +0000

I'm not sure all of this is editorial.  I'd prefer to have mailing list discussion of at least this one:

The state of promised streams is bound to the state of the original associated stream on which the PUSH_PROMISE frame were sent. If the originating stream changes to half or fully closed, all associated promised streams close as well.  More specifically, if the sender of the PUSH_PROMISE half-closes the original stream, the sender will no longer be permitted to send frames for any associated promised streams. Accordingly, the FINAL flag SHOULD NOT be set on a PUSH_PROMISE frame, as doing so would make it impossible for the sender to use the promised stream.

This prevents the client from considering the original request complete, and we’re requiring the server to maintain more state about the request that it’s finished answering, but it can’t half-close yet because it has other related streams that aren’t done yet.  That also means that a server might not explicitly half-close any pushed stream, and just let that be implied by the closing of the parent stream.  That feels unnecessarily round-about.

It looks like you’re pulling from 4.3.2, which says:

To cancel all server push streams related to a request, the client may issue a stream error (Section 3.5.2<http://http2.github.io/http2-spec/#StreamErrorHandler>) of type CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames for any streams with in-association-to for the original stream.

I think you’re trying to address the inconsistency that a particular error on the associated (original) stream flows to the pushed streams, and I agree with correcting that.  You’re addressing it by saying that any closure flows to pushed streams, and I hesitate on that.  I’d rather resolve it by saying that once a PUSH_PROMISE has been sent, the stream is allocated and has an independent lifecycle; if the client wants to reset that stream, the client should reset that stream.  If the client wants to reset many streams at once, the client should send stream errors for each stream it wants to reset.

-----Original Message-----
From: James M Snell [mailto:[email-masked]]
Sent: Friday, April 26, 2013 4:52 PM
To: [email-masked]
Subject: For review: editorial updates pull request

Another, fairly significant pull request with some suggested spec edits. Please review carefully, these are a bit more extensive than what I submitted yesterday...

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 29 Apr 2013 22:01:00 -0700

Well, it's editorial in the sense that I just rewrote what is already
in the spec. I think that this is still an open technical question tho
that, yes, we need to hammer out.

On Mon, Apr 29, 2013 at 3:13 PM, Mike Bishop
<[email-masked]> wrote:
> The state of promised streams is bound to the state of the original
> associated stream on which the PUSH_PROMISE frame were sent. If the
> originating stream changes to half or fully closed, all associated promised
> streams close as well.  More specifically, if the sender of the PUSH_PROMISE
> half-closes the original stream, the sender will no longer be permitted to
> send frames for any associated promised streams. Accordingly, the FINAL flag
> SHOULD NOT be set on a PUSH_PROMISE frame, as doing so would make it
> impossible for the sender to use the promised stream.
>
>
>
> This prevents the client from considering the original request complete, and
> we’re requiring the server to maintain more state about the request that
> it’s finished answering, but it can’t half-close yet because it has other
> related streams that aren’t done yet.  That also means that a server might
> not explicitly half-close any pushed stream, and just let that be implied by
> the closing of the parent stream.  That feels unnecessarily round-about.
>
>
>
> To cancel all server push streams related to a request, the client may issue
> a stream error (Section 3.5.2) of type CANCEL on the associated-stream-id.
> By cancelling that stream, the server MUST immediately stop sending frames
> for any streams with in-association-to for the original stream.
>
> I think you’re trying to address the inconsistency that a particular error
> on the associated (original) stream flows to the pushed streams, and I agree
> with correcting that.  You’re addressing it by saying that any closure flows
> to pushed streams, and I hesitate on that.  I’d rather resolve it by saying
> that once a PUSH_PROMISE has been sent, the stream is allocated and has an
> independent lifecycle; if the client wants to reset that stream, the client
> should reset that stream.  If the client wants to reset many streams at
> once, the client should send stream errors for each stream it wants to
> reset.
>
>
>
> Another, fairly significant pull request with some suggested spec edits.
> Please review carefully, these are a bit more extensive than what I
> submitted yesterday...
>
>
>