W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: HTTP/2 response completed before its request

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 01 Jul 2014 19:29:56 +0000
To: William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>
cc: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Jeff Pinner <jpinner@twitter.com>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <16322.1404242996@critter.freebsd.dk>
In message <CAA4WUYgM_uQyjCH3XYCtb3t7YzbUf66_6it6Hp4_H2xEeDu-Ow@mail.gmail.com>, =?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
http://example.com 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC