- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 25 Jan 2012 10:35:43 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Wed, Jan 25, 2012 at 09:12:24AM +0000, Poul-Henning Kamp wrote: > In message <20120125064534.GE32580@1wt.eu>, Willy Tarreau writes: > > >That said, there are a number of other issues in HTTP/1.1 that we could get > >rid of when switching to a new protocol : > > - get rid of the Host header and only use absolute URIs > > +1 > > > - get rid of content-length and only use transfer-coding (and get rid of > > 3 pages in the spec which explain how to determine a message's length) > > Actually your remaining three ideas can be combined into one idea: > > - Clearly split transport metadata from content metadata, for instance > by putting a blank line between them. I was thinking exactly about the same thing just after sending the mail, this would leave 4 parts in a message : - request/status line - transport headers - other headers - payload > That removes the need for a Connection header to say which transport > metadata to strip. exactly. > I would add a new header that tells how many seconds the connection > can be idle before it is closed. A value of zero has same semantics > as "Connection: close" has today. It's always a problem when a client advertises the expected connection time itself because many intermediaries cannot accomodate such timers, and issues result from the client expecting everyone in the whole chain to respect their timers. I'm already seeing stupid people complain from time to time that some haproxy deployments time out after something like 5 *minutes* without waiting for their response to come and that they want to configure infinite timeouts ! > That split also avoids the need to even parse the content metadata > for purposes of transport. Exactly. Regards, Willy
Received on Wednesday, 25 January 2012 09:36:51 UTC