Re: HTTP/2 response completed before its request

In message <>, =?UTF-8?B?V2lsbGlhbSBDaGF
uICjpmYjmmbrmmIwp?= writes:

>> Definitely.  But who gets the blame for the stall?
>The server. 

I'm not so sure.

The server acts sensibly:  A client which tries to POST a 1TB file to should not be able to tie up bandwidth and resources
for ages before the server can tell it to forget it.

The sensible client will stop transmitting on seing END_STREAM from
the server and put an END_STREAM on the next packet going out and
abandon the stream.

At the very latest, a modestly conforming client will discover
the servers END_STREAM when the window closes to zero, since it has
to shift to receive to get WINDOW updates.

The only question is what to do about non-modestly conforming clients
and intentionally malicious clients?

I would propose the server do something like the following:

	Issue no further credits towards the window, but let it
	close to zero.

	Discard all packets received on this stream.  If any of
	them contain END_STREAM, we're done.  (sensible clients)

	Once window is at zero, wait a couple of seconds.

	Issue a single window credit, only 100 bytes or so.

	If the next frame on this stream received from the client
	does not contain END_STREAM close the connection.

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.

Received on Tuesday, 1 July 2014 19:30:22 UTC