W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Rechartering HTTPbis

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
Message-ID: <20120125093543.GB2413@1wt.eu>
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.


> 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.


Received on Wednesday, 25 January 2012 09:36:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC