Re[2]: HTTP/2 Expression of luke-warm interest: Varnish

Hi all

After reading the reviews posted by/on behalf of twitter and facebook 
endorsing SPDY as-is (were they written by the same author?) I have to 
admit to getting the feeling we were going round in circles.

We had a long thread a few months back about whether encryption can be 
mandatory or not.  My understanding was that general consensus was 
achieved that it could not be mandatory, and that's why SPDY made it 
optional.  I suspect that deployment / interop issues with existing 
infrastructure play a large part in the desire to use NPN in TLS to 
establish support for SPDY or not, which provides a big incentive to 
push for TLS.  Frankly I don't believe it would actually improve 
security overall in the longer term.

Anyway, I would have a really big problem with any attempt to make 
encryption mandatory in the spec, and I think I (and others) already 
expressed the reasons before, so I won't repeat them here.  In the 
absense of any out-of-band negotiation of HTTP/2.0 support, and with 
the desire to not lose a R-T, we only really have 1 palatable option 
(other than using another port number which I still think may be 
preferable), and that's the Upgrade header.

Forgive me also for saying it looked like the FB and Twitter 
endorsements started from a position of having already decided SPDY was 
the way to go, and trying to justify that.  I can understand that, from 
their POV SPDY is really compelling, not the least because it is 
deployed and tested and has real benefits now.

And I don't have anything against SPDY, but I don't consider it to be 
HTTP. I see it as a transport / middle-layer which adds some nice 
features to transportation of HTTP/1.1 messages, but doesn't actually 
semantically change them (except for proposed server push, which AFAIK 
is still not really used?)

I'd like to see something that resolves some of the issues in HTTP 
itself, regardles of whether it goes over a multiplexed compressed 
encrypted connection or not.

>From a coding POV, I'd like to see 

* something that no longer requires parsing of strings or embedding of 
escapes to avoid conflicts with string-based token delimiters.  
* support from the ground-up for unicode
* less bloat

Also I'd like to see

* simplified caching controls that web developers can understand and 
use properly
* support for notifications
* support for scanning at an intermediary

overall maybe desire for simplification is a bit naive, but it still 
feels to me like there are a bunch of things that were patched on 
afterwards and had to be hacks.

Adrien




------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 16/07/2012 9:28:42 p.m.
Subject: Re: HTTP/2 Expression of luke-warm interest: Varnish
>We've agreed to how we're proceeding after extensive discussion previously.
>
>Changing that plan would require re-chartering, and while I hear a few people agreeing with you, I hear a lot more people who are committed to the path we're on. So, extra words from you at this point aren't going to do it; I need to hear broad consensus among people who implement and deploy HTTP to even consider this.
>
>Thanks,
>
>
>On 16/07/2012, at 7:16 PM, Poul-Henning Kamp wrote:
>
>
>>
>>In message <504E861E-C63B-466B-8E81-E6FC67DDDC7B@mnot.net>, Mark Nottingham w
>>rites:
>>
>>Mark,
>>
>>The goals you point to are however goals for a WG, and I think they
>>are good goals for a WG, but they are not goals for a protocol.
>>
>>Goals for a protocol would sound more like:
>>
>>* "90% of all first requests fit in one packet on 1500 byte MTU"
>>* "request-reponse model." / "peer-to-peer model"
>>* "All protocol elements must be fixed size or length prefixed."
>>* "Must have multiplexing and pipelining"
>>* "Cryptographic protection is included/optional/mandatory"
>>* "Has (no) out-of-protection routing envelope"
>>* "Can (not) mix protected and unprotected requests on same connection"
>>* "No-extra-RT upgrade from HTTP/1 to HTTP/2"
>>* "Must demonstrate 10Gbit/sec load-balancer implementation on COTS PC"
>>* "Client must offer unique device or user identifier"
>>* "Not allow cookies or other server initiated tagging of client."
>>* "Replace User-agent with something of finite size and preferably usable."
>>
>>and so on (examples only!)
>>
>>Picking what you call "a starting point" -- no matter which of the three
>>you pick -- will put many of these decisions outside the reach of the WG.
>>
>>Poul-Henning
>>
>>PS: Your argument that it's better to have SPDY inside pissing out
>>than outside pissing in, is just capitulation by a different name.
>>
>>--
>>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.
>>
>
>
>--
>Mark Nottingham
>http://www.mnot.net/
>
>
>
>
>
>
>

Received on Monday, 16 July 2012 12:02:48 UTC