short HTTP workshop notes

Poul-Henning Kamp phk at
Mon Aug 1 10:26:43 CEST 2016

As you may remember I spent a week of my summer vacation in Stockholm
participating in the HTTP workshop.

I want to make absolutely clear that the HTTP workshop is a Good Thing,
but at the same time it is deeply troubling.

The major troubling thing is that the Internet is rapidly getting
feudalized the way Bruce Schenier talkes about here:

New developments in HTTP protocol is almost entirely focused on what
the big feudal overlords, Google, FaceBook etc. needs.

For instance, there were, as far as I can tell, not a single
representative for any CMS or law enforcement present in Stockholm,
but there were multiple people from Google, Microsoft, FaceBook,
Mozilla, Akamai, Fastly etc.

There were two people from our end of the "ecosystem": Willy(HAproxy)
and me.

Proxies are considered outdated/unwanted technology by the big guys.
Interestingly the Google people in the workshop seemed to be unaware
that Google uses load-balancers.

So what happened ?

A review of H2 experience.  Breaking News: It's not fantastic and
a lot of the issues that were pointed out before ratification had
merit.  Too late now.

H2 _can_ be tuned to work, but it is non-trivial and most sites
don't know their traffic well enough and don't have the resources.

Very few FOSS projects which support HTTP supports HTTP2, they
lack developer bandwidth.

Newsflash!  PUSH is not magic.  One report: 47% of all pushes rejected.

Band-aids have been proposed for that (cache-digests draft), but a
(complex) band-aid on top the PUSH band-aid were not exactly cheered
on.  Simpler solution may be almost as effective, for instance
just count of cached objects for that host.

Google has dumped the QUIC UDP transport onto IETF, the same way
they dumped SPDY in there:  "Take it or leave it, we're doing it

I cloned their github, got 600KLOC, but only about 20-30KLOC seems
to be the actual protocol.  Not thrilled.

Q: Have you planned on standardized QUIC APIs to avoid the
OpenSSL/HeartBleed lock-in problem?  A: No, not our job.

At least Microsoft & I disagree.

HTTP3 to HTTP6 were mentioned in various levels of jest, everybody
seems to recognize that H2 is not the end.

Increasing desire to draw a dotted line through HTTP separating
purely semantic stuff from stuff transports may have to deal with.

Still N-1 consensus that "we can out-encrypt the politicians" but
zero desire or intent to increase client privacy wrt. server
(user-agent, cookies, fingerprinting etc.)

Most TLS1.3 implementations now talk to each other.  Aims for
release this autumn.

TLS1.3's "0-RTT" brings a new level of complexity, since the "0RTT data"
does not have replay protection.

FaceBook raised important detail for 0RTT requests:  Difference
between idempotent (can be retried/replayed and does no damage) and
replay-safe (can be replayed and does neither damage nor leak

Some effort to get a common structure for new headers going forward,
but JSON has too many problems.  Wrote straw-man on the way home in
train, we'll see.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.

More information about the varnish-dev mailing list