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

In message <CABaLYCswvXipBNsjFDnmEUR2AbVow6uLe+7uLJ0RD2wY_8US_w@mail.gmail.com>
, Mike Belshe writes:

>You've got it in your
>head that a the people that started on this work are idiots and unopen to
>public debate.

No, I'm very impressed by what the SPDY has done, I've said so
repeatedly.

>Do you think the other companies - from Facebook to Twitter [...]

I think they are all very big companies with world wide distribution
of http-server facilities.

Most websites have only one geographical location.

This "we're everywhere" bias showed up in the initial release of
SPDY numbers, which looked wonderful, thanks the the fact that Google
has low RTT to anybody in the world, and thus could "afford" the
TLS-RTT penalty, a luxury not many websites have.

But my major problem with SPDY is simply that it is additive,
it just adds another 50 pages of sediment to the pile of RFCs
necessary to implement HTTP.

SPDY does nothing to address problems like User-Agent, Cookie,
ASCII representation of timestamps, it just throws it all
into deflate and hopes for the best.

Take the discussion going on about "non-GMT" timestamps right
now as example:  Resolving that is probably going to add another
20 lines of text to clarify.

If HTTP/2.0 defines all timestamps as a POSIX::time_t binary
timestamp, you can rip out the entire section 8 out of part2, 
eliminate tons of weird error-cases and their handling, and
everybody in the HTTP-chain will save cpu cycles.

That is the sort of improvement I expect from HTTP/1 to HTTP/2
and SPDY does not deliver it.

-- 
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 Monday, 16 July 2012 15:16:30 UTC