Re: Rechartering HTTPbis

Hi Poul-Henning,

On Tue, Jan 24, 2012 at 08:13:20AM +0000, Poul-Henning Kamp wrote:
> One year ?  Yeah, right, as if.

Well, if we announce one year, maybe we'll manage to succeed in 3.

> Looking at the above, the only activity I credibly see us perform
> is to beatify SPDY.
> 
> >* More efficient use of network resources; in particular, reducing the
> >  need to use multiple TCP connections
> 
> So we're just going to ignore that SCTP already solved this problem
> and many other problems, because we just need this as hook to approve SPDY.

Maybe HTTP/2.0 could be designed to take advantage of SCTP.

> >* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
> >  presence of NATs
> 
> Apart from "no reverse connections" I have no idea what this means.

My understanding is that we must respect the current model where there is
no need to know the address of the peer anywhere for the protocol to work.
This is what already makes HTTP work very well over UNIX sockets for
instance.

> >* Maintaining HTTP's ease of deployment
> 
> I think this is fundamentally at odds with SPDY's design.
> 
> You can write a HTTP webserver in any language or facility that can
> do ASCII text, I have even seen such a webserver written in INTERCAL.
> 
> SPDY has a very high barrier of entry, zlib compression and a lot of
> state, so what exactly do we mean ?

Maybe the points you're expressing are some of the ones to consider
with higher priority to maintain ease of deployment. I was also thinking
that adopting an Upgrade-based protocol could ease transition.

> >* Reflecting modern security requirements and practices
> 
> Ohh, interesting:  Security against who ?  Security against your
> ISP or mobile carrier injecting unwanted ads ?  Security against
> your government censoring your web-experience ?  Security against
> cross-site-scripting ?  Security against potempkin CA's ?

First, any protocol should have strong requirement for being unambiguous.
Some HTTP implementations are prone to content smugling attacks because
the protocol offers few borders. Everything that affects contents cannot
be considered as part of the security model, however the model should
ensure there are provisions to protect contents (eg: use of TLS when
needed).

> I could see the discussions take more than a few months, just on this.

Even more maybe, based on what we saw on hybi, but that's normal.

> >In documenting this protocol, the Working Group must:
> >* Meet the goals specified above
> >* Make it possible to pass through a HTTP/1.1 message with reasonable
> >  fidelity; i.e., to implement a gateway to or from HTTP/1.1
> 
> Ok, any protocol worth its salt can pass through a blob of bytes and
> call it "a passed through HTTP/1.1 message", but what's the point ?
> 
> Where is it going to come from and where is it going to go ?
> 
> And why ?

What's most likely to happen is that browsers will quickly adopt the
protocol, and servers will take ages to upgrade. If the protocol offers
real benefit over high latency links (eg: mobile networks), it can make
a lot of sense to implement HTTP2-to-HTTP1 gateways to help many sites
present an HTTP2 interface to the world. That's exactly what is currently
done with IPv6, many sites offering IPv6 connectivity are in fact IPv6
up to the gateway, then IPv4 locally.

> >* consider the needs of a variety of HTTP implementers and users
> >  (such as "back-end" or "web api" uses of HTTP, servers and intermediaries)
> 
> Ohh, so we are going to cater to "intermediaries" who want to censor the
> web ?  I guess we were talking "job-security" then ?

Intermediaries are products such as yours and mine :-)

> >* Address HTTP proxy and CDN infrastructure requirements
> >
> >Changes to the existing semantics of HTTP are out of scope in order to
> >preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
> >request chain. However, the effort may define new semantics to further the
> >goals above, along with suitable extensibility mechanisms for defining
> >additional semantics.
> 
> So, we are not going to actually solve any of the semantic problems
> we created, we're just going to wrap the usual mess in a compressed
> protocol called SPDY ?

Not necessarily.

> >This work will be known as "HTTP/2.0", unless the Working Group
> >determines that this isn't suitable (e.g., for interoperability).
> 
> I really don't think it qualifies for that pretentious name, because
> all it is set up to be, is tunneling HTTP/1.1 more efficiently
> through the tubes.
> 
> In my mind, the effort sketched out would be correctly titled
> "Beatify the SPDY protocol as a carrier of HTTP/1.1 traffic"
 
HTTP/1.1 has a number of issues that make the current spec very
heavy and implementations complex (eg: remember you can't fold
set-cookie, the issues with multiple content-length, etc...).
Taking the opportunity of a new version to clear a few of these
old issues would be nice.

> HTTP/2.0 would in my mind be an attempt to actually improve the
> protocol, possibly going as far as replacing everything but the
> first line which we would have to keep, to ensure the ability
> to interoperate with earlier HTTP protocols)

Maybe that's an option too.

Regards,
Willy

Received on Tuesday, 24 January 2012 08:48:45 UTC