W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #282: Recommend minimum sizes for protocol elements

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 25 Jun 2011 09:14:38 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, David Morris <dwm@xpasc.com>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <20110625071438.GF5307@1wt.eu>
On Sat, Jun 25, 2011 at 05:06:03PM +1000, Mark Nottingham wrote:
> > Would this be too evil ?
> > 
> > 	If the underlying transport protocol advertises or negotiates
> > 	a receive buffer size, such as the TCP window, Clients
> > 	SHOULD NOT send HTTP requests larger than this size.
> > 
> > This would allow really tiny implementations, such as Contiki, to
> > inform the world about their limits.
> That ignores proxies; the window size is effectively hop-by-hop (from an HTTP standpoint), and anyway this will cause people to complain about layer violations.

That's my fear too. Also it's more a matter of designing applications
to support a well-known value than to make UAs and servers agree on a
size : if your app requires large amounts of data to be sent, send them
as POST and not headers. Once the app is designed to work the wrong way,
whatever will be advertised by the other end will not change the issue,
if it can't work it's too late.

> > Also, I assume it is obvious to everybody, that the header size we
> > are talking about includes the two CRNL sequences at the end ?
> We'll need to go to that level of detail when we write the text, yes. It seems reasonable to include it.

Indeed it was obvious to me too, as the request is only complete
once we get to that point.

Received on Saturday, 25 June 2011 07:15:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC