- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 16 Jul 2012 12:02:14 +0000
- To: "Mark Nottingham" <mnot@mnot.net>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
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