RE: For review: editorial updates pull request

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:jasnell@gmail.com]
Sent: Friday, April 26, 2013 4:52 PM
To: ietf-http-wg@w3.org
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...



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




- James