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 14:57:09 +0100
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20120125135709.GG2413@1wt.eu>
On Thu, Jan 26, 2012 at 02:36:30AM +1300, Amos Jeffries wrote:
> >   - make the connection header mandatory and at a fixed position (eg: the
> >     first one), this would greatly improve parsers performance
> 
> I disagree on the performance benefit from fixed position.

When I said "fixed position", I used the wrong term, I meant that
I wanted a few of them at the beginning to avoid the two step
phase consisting in :
  1) find the connection header(s) among the whole headers
  2) find the referenced headers among the whole headers

As we exchanged with PHK in the same thread, having two parts would
greatly simplify the design and the parsing... And what you suggested
too below :

>  Perhapse even splitting the list of hop-by-hop headers into a 
> specifically marked block which can be wholesale dropped or relayed 
> unparsed.

so in short :
  - first line
  - transport headers (hop-by-hop)
  - '\n'
  - other headers
  - '\n'
  - payload


> (drat. you suckered me into design again).

An me too. The temptation is too strong to resist :-)

> The things I really dislike you have mentioned already:
> * Host: being separate from the URL
> * free-form headers like User-Agent, Server, and Via () comment blocks. 
> no need for free-form, define a standard syntax please
> * Accept-*: being able to duplicate as Accept: entries. ugh.
> * size of the headers section not being known up front.
> * weak ETags. Still dont get the point of these. Either its a current 
> unique ID or its not.

Good point on the ETags, I've been used to observe caching issues in
load balanced farms because all servers emitted different ETags and
each time a static object was conditionned by an "if-none-match", it
would obviously not match.

Regards,
Willy
Received on Wednesday, 25 January 2012 13:57:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT