Re: RST_STREAM(OK) after an HTTP response

Ping. 

> On 15 Oct 2014, at 4:45 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
> On 15 Oct 2014, at 3:59 am, 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.  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.
>> 
>> 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 think that's where we're at, given the data from Amos (which seems right to me based upon my experience, FWIW).
> 
> One way we could go here would be to loosen the requirement (e.g., SHOULD NOT, ought not). Arguably, this should have been clarified in HTTPbis (since the semantic is independent of version).
> 
> What do people think? 
> 
> Regards,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 22 October 2014 03:22:54 UTC