Re: Rechartering HTTPbis

On 25/01/2012 7:45 p.m., Willy Tarreau wrote:
> Hi Amos,
>
> On Wed, Jan 25, 2012 at 03:49:48PM +1300, Amos Jeffries wrote:
>> Given my very brief abstract "truncating the common header names" how
>> easily would you (already familiar with HTTP/1.1) interpret this blob:
>>
>>   GET / HTTP/2.0
>>   H:example.com
>>   CC:max-age=0
>>   CNC:close
>>
>>   HTTP/2.0 200
>>   D:20120125-153200UTC
>>   ET:aswa$sf345
>>   EL:5
>>   \n
>>   hello
>>
>> Hard? no.
>>
>> ~30% more compact.
> I really like the principle, its still quite readable and makes a smarter
> use of upstream bandwidth in highly asymmetric setups (eg: 3G). And having a
> single LF instead of CRLF is nice too, as it's quite boring to have complex
> parsers that need to have an additional state to handle the case where CR
> was seen without LF yet.
>
> Note that this format could be HTTP/1.2 since it's still compatible with
> 1.x messaging.
>
> 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)

+1. I've tried to use that in the above example. "EL:" meaning 
Entity-Length, with no ambiguity about meaning of "Content".

The first chunk can even be a blob of MiME headers from current HTTPbis 
Drafts parts 3-7 . Which leads to...

>    - 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. Except for 
Date these are all variable in length headers, which means parsing them 
all anyway. The gain would be coming from making a very small set like 
above which are mandatory to be first, and leaving other extended 
feature headers in an extension blob which can be skipped blindly. 
Optimization taking lessons from the way IPv6 extensions work.
  Perhapse even splitting the list of hop-by-hop headers into a 
specifically marked block which can be wholesale dropped or relayed 
unparsed.

(drat. you suckered me into design again).

>    - have all the connection-related headers first (or maybe optional and
>      inheritable from the first request as long as the connection is kept
>      open).
>
> These are just examples, of course, and it's too early for that, but we
> all have to start thinking about what we dislike with the current model.

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.

AYJ

Received on Wednesday, 25 January 2012 13:37:17 UTC