Re: RST_STREAM(OK) after an HTTP response

On 15 October 2014 05:59, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> On the text itself, I would make it a SHOULD NOT.  A client can already discard a response any time it wants, for any reason it wants.  Why is this one in particular deserving of an absolute prohibition?
>
> Regardless, I don't think the issue is an incorrect implication of a state change on the wire, though if you want to make that clearer feel free.  There is an actual new state in the code that has to be introduced to support this, even if it's conceptually a "normal" RST_STREAM.
>
> Upon receiving the RST_STREAM, we can't send any more body to the server.  But we also can't stop the layer above us from pumping body into us without aborting the request.

Isn' that dependent on the API you have? E.g. in python you could make
data being pumped at that point raise a specific exception. And then
no more data will be sent :).

Perhaps the implied but not stated thing here is that this is
different to HTTP/1.1 APIs where client code can assume that it just
needs to write all the data and then and only then it can read the
response is the problem: and this is indeed a difference to HTTP/1.1
:).

>  With any other form of RST_STREAM, we could just fail attempts to write more body, because the request was aborted by the server.  This form of RST_STREAM creates a new corner case that has to be handled in an API layer or an intermediary -- continue accepting body from the layer above, but route it to the bit bucket instead of the wire.

I don't think thats desirable, because its wasted effort - better to
signal the protocols capabilities back up the API stack more
faithfully. Its not actually a new protocol state: its a state in the
1.1->2 programming API thunk that you appear tohave :).

> It's certainly possible -- it's just more code -- but our point is that permitting this does create a new state for an intermediary to handle.  (Though it's a reasonable argument that this state already existed and the text just calls attention to it in case, like us, an implementer overlooked it.)

I'd certainly make that argument: early responses have been possible
for some time, and I presume thats not exposed in the API in question,
or your layer above would already be able to detect this in some form.

-Rob


-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud

Received on Tuesday, 14 October 2014 22:51:30 UTC