Re: RST_STREAM(OK) after an HTTP response

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/10/2014 11:51 a.m., Robert Collins wrote:
> 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
> 
> 

And I have some evidence here to back it up.
http://bugs.squid-cache.org/show_bug.cgi?id=3791
http://bugs.squid-cache.org/show_bug.cgi?id=3017

Intermediaries have been handling the early-response case for some
years in HTTP/1.x.

The referenced bug reports are for NTLM challenge with large POST/PUT
data still being sent. IIS servers are particularly well known for
doing that since years back.

It also happens frequently with CONNECT requests when server errors
are returned. SPDY and WebSocket connections are the top candidates
for causing that event.

So yes, response completion before the request has finished being sent
by the client (or intermediaries) is neither unusual nor a new event
in HTTP. Your API is just lacking the asynchronous functionality to
notice it until now. Or perhapse your API does notice internally but
is one of the many clients who abort the whole TCP connection in these
cases.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUPgLLAAoJELJo5wb/XPRjwvoIAN7ovyJo1SVQP6IMO0Agbh/e
i2uHHi15Ni/PIJ3letC8QtNeOHsQvMJ4RY0TniMVxpzqXOGAMpmcSoS3egE1TU6w
O6N1C+pf9Xn5ra/KGXoQzmgcSDMtjcH5LN9K5MNS9o4POMmh9ifmmYDX6LoqwSpf
jWPOfKFwcAcmEyWE3TBJmHUwUUhRA+atU9p7vDJkOejEPX2ZygKfuk1oJvd1/AaM
KTvA05cCFfCnvUbufhXj+HP11RxbE3gMDLZqZMJ3s/FNBW20x4yojIIkdzpvUWks
AHQQM3rdlHPCl9S0UsYbDNx5mxQPLMeuXOpPC2cV3GeQYKvC213/BCLUREL8+rw=
=LRA1
-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 05:15:33 UTC