Re: For review: editorial updates pull request

[James M Snell <[e-mail]>]

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
<[e-mail]> wrote:
> 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) 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:[e-mail]]
> Sent: Friday, April 26, 2013 4:52 PM
> To: [e-mail]
> 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
>
>
>
>
>
>