Re: HTTP/2 response completed before its request

On Tue, Jul 1, 2014 at 12:58 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CAEn92ToDQtLd=
> sqGNx0Q8G4KMENjnPvSfGtxJJUioyG8MXh_9g@mail.gmail.com>, Johnny Graettinger
> writes
> :
>
> >Like TCP, HTTP/2 streams are full duplex. From the server's perspective,
> >the stream was in a half-closed-local state. As in TCP, a stream in such a
> >state must be consumed or reset to avoid a stall. The server had the
> choice
> >of either, and did neither.
>
> Sorry, but that's a rubish argument.  When the HTTP server has sent you
> a 3xx, 4xx or 5xx, that is like getting a RST on a TCP stream:  The other
> end told you "We're done, go away" and that's why your application does
> not even get asked before the TCP stack replies with RST.
>

I'm with Johnny here. A HTTP/2 stream roughly mirrors a TCP connection.

I think conflating HTTP message semantics with the transport is a mistake.
If the server really wants the other end to go away, why doesn't it just
kill the connection with a RST_STREAM?

Moreover, the suggestion that the client should terminate sending the
request with an END_STREAM flag sounds wrong. Isn't that actually modifying
the HTTP request? I would think that you'd want the client to end the
request with a RST_STREAM.


> >Without knowing the application context, it's impossible to say what would
> >have been sensible client behavior, but it doesn't matter here.
>
> We know the application context:  The server closed the stream, and
> well-behaved clients can only respect that and shut up ASAP.
>
> The servers problem is that this is YADAV[1] in HTTP/2, so it needs a
> heurstic to tell inept clients form malicious clients.
>
> Poul-Henning
>
>
> [1] Yet Another Dos Attack Vector
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>