Re: Rechartering HTTPbis

Hi PHK,

On 24/01/2012, at 7:13 PM, Poul-Henning Kamp wrote:

> In message <4429D3C2-9696-4110-B5BE-60DFB8A3101F@mnot.net>, Mark Nottingham wri
> tes:
> 
>> HTTP/2.0
>> --------
> 
> I am going to play the devils advocate and throw a number of spanners
> in the general direction of the works:

Thank you. My *personal* responses below.


>> [...]we'll start by asking for proposals, considering them and selecting
>> one based upon the traditional IETF criteria of rough consensus and
>> running code.
> 
>> Goals and Milestones:
>> 
>>  Done        First HTTP/1.1 Revision Internet Draft 
>> 
>>  Done        First HTTP Security Properties Internet Draft 
>> 
>>  Feb 2012    Working Group Last Call for HTTP/1.1 Revision 
>> 
>>  Feb 2012    Working Group Last Call for HTTP Security Properties 
>> 
>>  Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a 
>>              Proposed Standard 
>> 
>>  Apr 2012    Submit HTTP Security Properties to IESG for consideration as 
>>              Informational RFC
> 
> Where is that "ask for proposals yadda, yadda, yadda..." stuff ?

That's implicit at the start. IETF milestones are usually quite brief.


>>  May 2012    First HTTP/2.0 Internet Draft
>> 
>>  May 2013    Request Last Call for HTTP/2.0
>> 
>>  Jul 2013    Submit HTTP/2.0 to IESG for consideration as a Proposed
>>              Standard
> 
> One year ?  Yeah, right, as if.
> 
> Looking at the above, the only activity I credibly see us perform
> is to beatify SPDY.

IETF milestones are also pretty much always optimistic. If we don't have consensus on a decent starting point soon, we'd need to revise them (as often happens). 

However, if that does eventuate, I strongly suspect that the people experimenting with SPDY will continue to do so, leaving any standards effort on another track without much momentum (HTTP implementers, please prove me wrong on this, with code).


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

No, you're going about it wrong. SCTP is easy to argue against; as others have said, it has deployment issues for something as popular as HTTP (and AIUI SCTP over UDP doesn't count).

The real devil's advocate position here is behind BEEP...


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

Ability to be deployed without firewall / nat configuration on a scale that's appropriate to HTTP/1.x's current deployment.


>> * 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 ?

I wrote a SPDY client/server Python library in a very small amount of time; it has significantly less code and complexity as compared to the equivalent HTTP/1.x library. It was significantly easier to get running, and to debug. The hardest part was getting direct access to the zlib api, and that turned out to be ~100 loc, with tests <https://gist.github.com/242459>. YMMV.

If the WG adopts SPDY, my concerns are mostly around their mandatory use of TLS with NPN for negotiation. I also suspect that some form of negotiation for header compression will emerge, but it's early to tell.


>> * 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 ?
> 
> I could see the discussions take more than a few months, just on this.

Yes, they could. In my experience, security-related discussions regarding protocols can either take years, because everyone's an expert and there's no clear requirements or solution, or they're very brief, because there's already an existing, pragmatic solution that is good enough (but not perfect). YMMV.

The real requirement here (and it should probably be clearer) is that there's Mandatory to Implement security -- something that 1.1 doesn't have. 


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

To have one way to do it. We could start with HTTP-NG, SPDY, BEEP, whatever -- the important thing is to have a single way to do it, and get implementation.


> Where is it going to come from and where is it going to go ?
> 
> And why ?

?? Are you speaking metaphysically here, or?


>> * 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 ?

I wish; IME job security of HTTP intermediation expertise on its own is a touch-and-go sort of thing.

WRT censoring the Web -- even SPDY in its current all-TLS-all-the-time form doesn't help against censorship; the flaws in the CA system are very well-known. If we were serious about this (which is a big IF), we'd need something new (DANE as a starting point, perhaps?).


>> * 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 ?

Many of the semantic problems have already been clarified in HTTPbis. For the rest, see below.


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


Getting a new serialisation of HTTP's semantics onto the wire specified, implemented and interoperable is a massive task. Starting with a clean slate and letting a committee natter over it for years is a recipe for disaster, and I'd really rather not waste my time on it. 

But hey -- if implementers line up and want to do that, and support it with serious resources, we can go there. I haven't seen it yet. 

I'm willing to listen to the implementers about what they want in this protocol, and to fight people who rock up with bright ideas but nothing else. This cannot be a rubber-stamp effort on SPDY (or whatever else), and it cannot be a love fest to rewrite the core of the Web. There's a fine tightrope to be walked.

I'm also willing to wear appeals to the ADs and IESG if necessary. I'd rather make some harsh consensus calls and piss a few people off than make it a lowest-common-denominator effort. What I'm absolutely not willing to do is to specify a protocol that doesn't get serious deployment.

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

"2.0" means "not compatible with the syntax of 1.x on the wire". If marketing people read more into it than that, it's their problem.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 25 January 2012 07:18:20 UTC