- 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>
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. Regards, Willy
Received on Saturday, 25 June 2011 07:15:04 UTC