Re: RST_STREAM(OK) after an HTTP response

On 24 September 2014 16:28, Osama Mazahir <OSAMAM@microsoft.com> wrote:
> But that the validity of the bodies in-flight (or buffered on either
> send/recv) is the same as the other reset codes.  That is, all bets are off
> and I expect most stacks to implement immediate stream termination by
> dropping any buffered data on the floor.  I do not want us to get into a
> situation where bodies/requests/responses are expected to be valid, be it
> partial or ‘complete’.

There is another potential way this could work.  There are two ways a
client might consider a request "done", either the presence of
END_STREAM on the response side of the stream OR the transition of the
stream into the "closed" state.  This latter option that really causes
issues.

Then there is the concern above, where the RST_STREAM acts as an
interrupt and a trigger for the request being destroyed.  This seems
far more likely to me, partially because it's basically an essential
part of how you implement RST_STREAM handling anyway.

If people are generally OK with a clarification, either because their
implementation handles this gracefully, or because they are willing to
make the necessary changes, then I think we should make the change.
It seems like a valuable feature.  But I don't want to be saying
things about this if it is going to cause implementations considerable
pain.

Would the clarification Jeff requests break your implementation?  (And
are you unable or unwilling to make a change?)

Received on Thursday, 25 September 2014 07:17:50 UTC