Re: HTTbis spec size, was: Rechartering HTTPbis

On Sat, Jan 28, 2012 at 10:28:38AM +0000, Poul-Henning Kamp wrote:
> In message <4F23B745.3060002@gmx.de>, Julian Reschke writes:
> >On 2012-01-28 09:41, Poul-Henning Kamp wrote:
> 
> >If you feel that any of what was added isn't needed then please follow up.
> 
> Ok, yes, let me follow up, which ironically is going to take
> some length, because I probably have been a bit too brief
> and summary during a stressed work-week.
> 
> As I said earlier:  I consider HTTP/1.1 a lost cause, and I think
> the time spent trying to un-loose it has been wasted, except for
> any lessons hopefully learned, about what not to do.
> 
> One of the main nightmares, if not THE fundamental mistake, of
> HTTP/1.1 is the intermingling of transport and content.
> 
> The OSI protocols sucked, but there are some very tangible benefits
> in sound layering which we hopefully should have learned from them.
> 
> The transport/content mixup is so fundamental in HTTP/1.1 that
> most people don't even realize it, so here is a little quiz:
> 
> Which 3 tokens of this HTTP request is transport information:
> 
> 	>>> GET / HTTP/1.1
> 	>>> Host: www.example.com
> 	>>> User-Agent: fetch libfetch/2.0
> 	>>> Connection: close
> 
> Answer: "HTTP/1.1", "www.example.com" and "close".
> 
> Everything else is content, including "GET".

It's not that black and white nowadays. Many sites "route" by URI,
meaning the "/" is also part of the transport to some extent (eg:
route to static servers rather than application servers).

> The mixup happens because in HTTP/1.1 "GET" is also used to define
> the transport semantics, for instance the precense/absence of object
> bodies in the transaction.
> 
> That's just plain wrong: If you intend to send a body, there
> should be a clear, dedicated transport indication of it.
> 
> HTTP is short for Hyper-Text TRANSPORT Protocol and while we cannot
> do anything about the "Hyper-Text", (except be happy Tim didn't
> come out with 10 years earlier: "Turbo-Text Tranport Protocol"
> whould have been awful :-)  we can and should respect the TRANSPORT bit.
> 
> HTTP/2.0 should *only* be a transport protocol.

I don't think so because it will not solve current issues and will
not even replace what HTTP initially was (remember HTTP/0.9 that was
only able to retrieve a file without any header nor anything related
to transport ?).

However I think that there should be several very clear layers in HTTP2, so
that we get rid of this mixup and ensure that intermediaries can focus on
their own job without caring about upper layers. Right now I've identified
(from top to bottom) :

     4- payload         -> path, content-types, etc...
     3- session         -> cookies, user info, auth
     2- scrambling      -> TLS or whatever comes next
     1- transport       -> MUX, pipelining, keep-alive

We also still want to support untrusted proxies (eg: your ISP's), so it
is possible to stack layers 1, 2, 3 below this when talking to proxies :

 proxy  < 4- payload         -> path, content-types, etc...
   to   < 3- session         -> cookies, user info, auth
 server < 2- scrambling      -> TLS or whatever comes next
  ----  < 1- transport       -> MUX, pipelining, keep-alive
 client<  3- session         -> cookies, user info, auth
   to  <  2- scrambling      -> TLS or whatever comes next
 proxy <  1- transport       -> MUX, pipelining, keep-alive

Obviously some layers are not always present. For instance, if you acces
a proxy without any need for authentication, you might want to use only
layer 1 to talk to the proxy on top of which you can stack 1-to-4 to
communicate to the server. That also fits very well Adrien's proposal of
"GET https://".

The big benefit I see with such a layering is that it's easy to split it
into 4 parts which are worked on in parallel by different teams. For
instance I'm a total loser when it comes to contents and I'm sure the
cache and content filtering guys know that much better than me. However I
have my views on current shortcomings at the transport layer which need
to be addressed (eg: bad interaction with TCP due to congestion control
or early RST on close), and on what costs a lot to products operating at
this layer.

> So cut to the bone, what HTTP/2.0 should be able to do is:
(...)
For me this is layer 1 above. As long as you're interested in working
on this layer, you can then let other people work on the other layers
without declaring them useless.

> For starters, being DoS resistent (#4) is a lot harder than most
> people think in a client-server scenario.

Agreed!

> HTTP/1.1 interop (#5) needs some serious thought, because we don't
> want to expend a RTT on it.  The easiest way is probably to make
> the first transaction on a new TCP connection be HTTP/1.1 by default,
> unless we already know that destination to be HTTP/2.0 able, in
> which case the initial HTTP/1.1 transaction can be a costless
> "UPGRADE".

I too vouch for the Upgrade method, it's cheap, compatible and saves
one round trip thanks to the "1xx is not final" statement :-) It even
allows the server to respond with 2.0 semantics.

> We should not break the strict client-server model (#9), that would
> just be asking for security holes and implementation complexity.
> 
> The "server push" people desire, can be simulated inside a strict
> client-server model with multiplexing (#6) and transactions that
> just never seem to end.

That can be left to WebSocket which is already handling this after
an 1.1 Upgrade too. In fact 1.1 could be the common point to upgrade
to newer protocols.

Regards,
Willy

Received on Saturday, 28 January 2012 13:40:45 UTC