Re: Rechartering HTTPbis

+1 phk

Why is SPDY consistently compared to HTTP instead of https?  How does one midtier cache public stuff with encrypted headers?

----- Original Message -----
From: phk@phk.freebsd.dk
To: mnot@mnot.net
Cc: ietf-http-wg@w3.org
Sent: Tuesday, January 24, 2012 1:16:10 AM GMT -07:00 US/Canada Mountain
Subject: Re: Rechartering HTTPbis

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:

>[...]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 ?

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

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

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

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

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

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

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

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

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

Please be honest...


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 24 January 2012 08:55:16 UTC