
HTTP/3: from root to tip - jgrahamc
https://blog.cloudflare.com/http-3-from-root-to-tip/
======
oxymoron
Here’s another good intro, from a few days ago, by Daniel Stenberg of curl
fame: [https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-
video/](https://daniel.haxx.se/blog/2019/01/23/http-3-talk-on-video/)

He also has a free book about HTTP 3, over here:
[https://daniel.haxx.se/blog/2018/11/26/http3-explained/](https://daniel.haxx.se/blog/2018/11/26/http3-explained/)

------
cryptonector
Is it the case that HTTP/3, like HTTP/2, will not change the semantics of HTTP
in any way?

One thing that drives me nuts, for example, is that Expect: 100-continue
exists but has no criticality, so a user-agent can't tell at all if the 100
continue will be coming, or if a 2xx, 3xx, 4xx, or 5xx response will be sent
immediately. In principle the user-agent could use OPTIONS to detect if the
server implements Expect: for the target resource, but there is no guarantee
that a server that supports Expect: will note that in responses to OPTIONS.
Some clients implement a timeout then begin sending the request body, but
suppose when they do so the server's 3xx/4xx/5xx response is already in-
flight? Then the server will expect a new request, not a request body, next
from the user-agent. What a mess.

And, of course, Expect: is a very important feature. It's needed to avoid
sending data that cannot be recreated, or without having to cache it in order
to resend it if the request failed with a 401, say.

What I'd like to see is a hard requirement that OPTIONS must indicate whether
the server supports Expect:. I'm not sure much more than that can be done to
fix the problem. But obviously, a new transport for HTTP can't change this
sort of semantics, as one might be gatewaying to/from HTTP/1.1.

~~~
Matthias247
Is that really a HTTP/[2|3] problem, or a problem of those servers?

As far as I understood the HTTP/2 spec (have read this, but not HTTP/3), it is
allowed for servers to send an arbitrary amount of informational headers
(incl. 100-continue) before sending the actual headers and response body. So
everything to handle these kinds of requests should be in place.

If the server ignores the "Expect: 100-continue" there is obviously nothing
the other side can do, but that's the same in HTTP/1.1.

What I am a bit unsure about is actually how things like "transfer-encoding:
chunked" or the various "connection" headers are supposed to be handled in
servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2\. Is
this supposed to be automatically set on the lower level, depending on the
actual protocol type. And the application level HTTP client or handler on
server just sees the body as a stream? I'm not sure if that happens currently
in common libraries, or whether they would forward these things if a client is
connected via HTTP/1.1 and not when it's connected via HTTP/2.

~~~
cryptonector
> What I am a bit unsure about is actually how things like "transfer-encoding:
> chunked" or the various "connection" headers are supposed to be handled in
> servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2\.
> Is this supposed to be automatically set on the lower level, depending on
> the actual protocol type. And the application level HTTP client or handler
> on server just sees the body as a stream? I'm not sure if that happens
> currently in common libraries, or whether they would forward these things if
> a client is connected via HTTP/1.1 and not when it's connected via HTTP/2.

Section 8.1.2.2 of RFC 7540 [0] covers most of what you ask except that it
doesn't explain how chunked transfer-encoding maps to HTTP/2, and section
8.1.3 [1] shows an example of mapping chunked transfer-encoding onto HTTP/2
data frames.

Basically, in HTTP/2 all transfers are necessarily "chunked" into DATA frames
[2] (necessarily because of multiplexing of channels!), and Content-Length
-when present- merely indicates what all the chunks must add up to.

    
    
      [0] https://tools.ietf.org/html/rfc7540#section-8.1.2.2
      [1] https://tools.ietf.org/html/rfc7540#section-8.1.3
      [2] https://tools.ietf.org/html/rfc7540#section-6.1

~~~
Matthias247
I am aware how bodies are streamed in HTTP/2 (I have written an
implementation). What I am not sure about is how libraries on client and
server side are expected to handle this kind of information. A Lot of servers
and client libraries might display "transfer-encoding: chunked" to their user,
even though that wouldn't be seen if the connection was established via
HTTP/2\. It's more of a question of "how to hide those protocol differences
from the user while still allowing them to set and access all information if
required". And the question whether the HTTP ecosystem already embraces that,
or whether most libraries still expose all the HTTP/1.1-only ways to the user.

------
Matthias247
Great article about the HTTP history!

Only one thing I would change: The article mentions the term "syntax" very
often, but I don't it is the best choice. When I read syntax, I think about
something human-readable, e.g. about programming language syntax. What is
really meant is "wire-level encoding" or "serialization format". I think
[wire-level] encoding might be the most common used term for protocols.

~~~
garmaine
Which is also syntax. It’s the correct word choice.

~~~
javajosh
This is not my understanding of the word "syntax". Indeed, if you read
[https://en.wikipedia.org/wiki/TCP/IP_Illustrated](https://en.wikipedia.org/wiki/TCP/IP_Illustrated)
you'll not see the word "syntax" used to describe the protocol layout. So,
basically I agree that the word is misused in the post. I think "layout" might
work better.

~~~
cryptonector
It's one of those words whose meanings in the industry vary a fair bit
contextually.

So, for example, ASN.1 defines syntax for expressing schemas (ITU-T x.680 and
others in the x.68x series), and also encoding rules (x.690 and others in the
x.69x series).

XDR is one standard for both, syntax and encoding.

In HTTP land syntax is used to refer to encoding. In HTTP/1.x, because the
protocol is textual and specified in ABNF, syntax can refer to both things
equally well. In HTTP/{2,3} this is no longer the case but it doesn't matter,
we continue to use "syntax" to refer to the encoding.

------
seabrookmx
Tangentially related.. like HTTP, Websockets currently operate over TCP.

Is there plans to port them to QUIC as well? It's been many years since my
networking class but I'd assume Websockets would stand to gain quite a bit as
well.

~~~
est31
Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch
request, any existing keepalive connection to that server is used, so the
overhead that pre-HTTP/2 XHR connections needed is lost and with it the
advantage of Websockets.

~~~
crgwbr
Honestly curious: how would you use HTTP{2,3} to push a real-time message from
server to client without a WebSocket? Are we back to just long polling?

~~~
jrockway
gRPC is already HTTP/2.0 and has bidirectional streams. I imagine it would
work like that.

Browsers are almost at the point where they can just talk gRPC to the backend,
but gRPC uses HTTP trailers which browsers do not support.

I don't think, from a networking standpoint, that websockets was really
necessary. A browser and a web server already have a socket open that they
send messages in either direction on. It's just so much of the web was
designed around "client asks for something, server sends the result and closes
the connection" that some transition period was necessary to distinguish
between the two cases. (You didn't necessarily provision your web server for
maintaining hundreds of thousands of open connections.) But now that people
are used to the idea of connections sticking around in the context of HTTP,
it's no big deal to send arbitrary data over that connection.

~~~
icebraining
But can the client in HTTP/2 send more data to the server after it has
received something, without having to send a full HTTP request? If not, I
don't see how something like agar.io, which requires constant updates to the
server on every mouse movement, can work without tremendous header overhead.

------
getcrunk
A thing I always notice about new tech is a failure to simply and concicsely
explain what it is. I had to click through a few links and I still couldn’t
find a one paragraph summary of what quic was. If it doesn’t have a large
number of influencers mind share it won’t move quickly (don’t mean that
absolutely)

~~~
spc476
A crude, TL;DR is that QUIC is just TCP over UDP.

~~~
getcrunk
That’s all I wanted lol thanks

------
electrotype
I'm curious on why the upgrade mecanism to tell the server you understand and
prefere HTTP3 is different from the one used to upgrade to a Websocket
connection? It doesn't seem to use the "Connection: Upgrade" and "Upgrade:
XXX" headers but rather "Alt-Svc"...

I'm a total newbie on the topic, so I'm curious about this.

~~~
treve
Because you aren't just switching the 'format on the wire', you are switching
from TCP to UDP, which requires a new IP connection.

------
erickj
The proliferation of future protocols that will never fully be adopted is
simply creating an fractious and overly complicated mess.

examples:

IPv6 migration. This is the best case, given that it was a necessity to combat
the exhausting pool of IPv4 addresses. Even such only ~25% client adoption
after 10 years. And worse support from websites in the alexa top 1,000,000
([https://www.internetsociety.org/resources/2018/state-of-
ipv6...](https://www.internetsociety.org/resources/2018/state-of-
ipv6-deployment-2018/))

HTTP/2\. Roughtly 35% adoption (by site) in the Alexa top 1,000,000.
[https://http2.netray.io/stats.html](https://http2.netray.io/stats.html)

HTTP/3\. Obviously less.

Now I'm not trying to make this point from the position of the grumpy old man
who doesn't want to learn something new. I love new tech, and obviously the
research and development of new protocols over the past 30'ish years has
created an explosion of new industry and communication patterns that have
indisputably changed the world and shaped modern life.

However... the marginal benefit of each protocol advancement is directly
related to it's usage (so I assume). The benefit the world saw (from the user
perspective) when switching from HTTP/2.0 from HTTP/1.1 was arguably zero (I'm
not saying it was exactly "zero", but I could argue that it was
imperceptible). With bridge technologies like WebSockets and
BOSH/Comet/"Hanging POSTS" it could be argued that HTTP/2 was effectively a
bandwidth optimization in most users lives (those users that use the sites
that offer support).

However, the additional complexity for developers to leverage these
optimizations is detracting from the development of otherwise useful service
offerings in the form of opportunity cost. This is because nearly every
optimization inherently incurs a complexity cost, e.g. supporting both
HTTP/1.1 and HTTP/2 is obviously more complex than simply supporting the
former. And you are supporting it even if your deployment process abstracts
the details away from you, e.g. debugging customer issues.

Formulating HTTP/3 when support for HTTP/2 is below 30% is simply an example
of standards bodies working on a tiny "easy" problem (make the web go faster..
which is important) rather than face the bigger problem, i.e. helping to scale
the worlds service providers a seamless migration path to adopt said new
technology.

/rant from a grumpy old man

~~~
21
I'm not sure what you're talking about. Supporting HTTP/2.0 for my site was
literally just adding the "http2" word to the listen directive of nginx. Since
it's also used as a reverse proxy, the backend app server remained HTTP/1.1.

And you still notice the difference in site loading speed if your site has a
lot of static assets.

~~~
erickj
How much traffic does your site serve? I'm not saying that turning the feature
on is difficult. Anyone reading hacker news can go and configure their
webserver to start serving this traffic....

but I can tell you that a site serving serious production loads (let's just
say 100 qps)... nobody is just "flipping a config" and sending the protocol
out the door.

------
benbristow
HTTP/2 only just seems to be gaining traction. Isn't even a default on NGINX
(hidden behind a server config option) and now we're moving to HTTP/3?

~~~
teacpde
I think what makes http3 really desirable and convincing to migrate to is its
improvements on mobile networking which is prevailing nowadays.

------
prdonahue
If you're interested on working on HTTP/3, QUIC, and the author of this post,
we're hiring a Product Manager for this team in our London office:
[https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=...](https://boards.greenhouse.io/cloudflare/jobs/1251515?gh_jid=1251515).

------
kpcyrd
Did anybody look into how this is going to work with proxies? It seems fairly
naive to standardize this without having a solution for that.

~~~
sowbug
QUIC connections are always encrypted and authenticated, so they should work
just fine with a CONNECT-style proxy that supports UDP. (I don't know for
sure; I'm just reasoning from first principles.)

EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful
concept except in very limited circumstances such as forwarding only to a
single destination, because there's no connection to establish that a proxy
server could know anything about. Maybe proxy servers don't have a place in a
QUIC world.

------
tylerl
TL;DR: The new QUIC standard being produced changes the way in which certain
HTTP concepts are encoded; it's not just an added layer upon which existing
HTTP/2 bits can written. Because the format changes, the protocol number must
be bumped as well.

------
RKearney
Does CloudFlare support HTTP/2 back to the Origin yet? Or are they still
afraid this will destroy the selling point of their Railgun feature?

~~~
manigandham
It does not: [https://support.cloudflare.com/hc/en-
us/articles/214534978-A...](https://support.cloudflare.com/hc/en-
us/articles/214534978-Are-the-HTTP-2-or-SPDY-protocols-supported-between-
Cloudflare-and-the-origin-server-)

------
maxk42
This is bullshit. Entrenching TLS in web standards is just handing the keys to
the internet over to malicious government entities.

We need security without TLS.

~~~
denormalfloat
Ok, what do you want to replace it with? You can't complain about the existing
system without offering an alternative. Saying the existing system sucks
doesn't help move the Internet towards something better.

~~~
maxk42
You could embed public keys in DNS records for one. But I'll admit I was
hoping someone who understands security better than I do would jump in.

All I know is that centralized certificate authorities act as choke-points
malicious governments can use to censor information.

~~~
cryptonector
That exists, and is called DNS-Based Authentication of Named Entities (DANE)
[0], and there are proposals for making use of that in TLS. There is no need
to start over for transport security. TLS 1.3 is very well designed and will
eventually support DANE.

    
    
      [0] https://tools.ietf.org/html/rfc6698

~~~
tptacek
The "DANE" proposal has been around for over a decade, and was actually
implemented (probably twice, but at least in Chrome) and then rescinded,
because it in practice doesn't work. But even if it did work, it would still
represent a further centralization of trust on the Internet, this time with
the central authorities that matter being effectively controlled by
governments. DANE is a dead letter.

~~~
ietf-dane
[ For the record, not an invitation to a futile further debate, given your
long-standing immutably-held views on DNSSEC. Since you'll probably say the
same about my work to get DANE for SMTP up and running, we can stop here. All
I can add is that those who say it can't be done should not get in the way of
the people doing it... :-) ]

No, the major providers did not get together to do MTA-STS because DANE was
bad. They did it because their existing DNS geo-balancing kit for e.g.
google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note
that Microsoft has a dedicated domain (outlook.com) for email hosting, and can
more easily do DNSSEC there without impacting their other "web properties".
Note also that Google now MX-hosts many customer domains on "googlemail.com"
rather than google.com.

So things are starting to change. Furthermore, there are now over 1 million
DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant
on first contact and uses weak CA-leap-of-faith DV authentication. It will
probably be enabled at the biggest providers by the end of this year, but as
you yourself said elsewhere, these providers are the threat, and if so,
securing email delivery to the user surveillance empires is not necessarily
that important. Mind you, they can play a useful role by enabling validation
and helping to keep the TLSA records of receiving systems valid, and perhaps
surveillance is not their business for paying customers...

~~~
tptacek
The IETF draft itself says that the primary motivation for MTA-STS is to
provide transport security when DNSSEC is "undesirable or impractical". You
don't have to take my word for it.

There are a million DANE-enabled DNSSEC domains because there are registrars,
particularly in Europe, that enable it automatically. Who cares? First of all,
DNSSEC managed by your registrar is security theater, but, more importantly,
the overwhelming majority of those domains _do not matter_. Who cares if some
landing page in the Netherlands has TLSA records?

Meanwhile, the domains that really do matter --- the ones managed by the major
mail providers --- are doing MTA-STS.

SMTP is not a success case for DNSSEC.

~~~
ietf-dane
gmx.de, comcast.net, freenet.de, mailbox.org, posteo.de and tutanota.de come
to mind as counter-examples as well as various universities, the German
parliament, various Dutch government domains, and a couple of thousand self-
hosted SOHO domains. But DNSSEC is axiomatically evil, so I must be wrong...

~~~
tptacek
Versus Google Mail, Yahoo, and Microsoft? And Comcast is also an author of
MTA-STS. So yeah, I'm pretty comfortable arguing that the verdict is in on
this.

Recall: the argument you're responding to (you drew it up from downthread) is
that DANE "definitely works for SMTP". Does it, now?

~~~
ietf-dane
Yes, DANE works for SMTP. Let's talk again in 2020. Ciao...

~~~
tptacek
Oh, I forgot; I made a helpful infographic for this last week:

[https://twitter.com/tqbf/status/1086061495811743747](https://twitter.com/tqbf/status/1086061495811743747)

~~~
ietf-dane
Yawn, would you also like to arm wrestle? I concede that smug superiority gets
more karma points than doing the hard work to make a difference.

Yes, only ~9 to 10 million domains are presently signed, and most of the
larger ones are not (but comcast.net and cloudflare.com are not tiny, and
gmx.de has over 10 million email users). Changing this takes time and effort.
Users still need better software tools that make deployment easier and there
needs to be less KSK deployment and rollover friction at the registrars and
registries (i.e. CDS support). Some DNS hosting providers with outdated
software need to upgrade their stacks, ... this does not happen overnight.
Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly...

~~~
tptacek
Cloudflare _sells DNSSEC services_. Comcast is actively participating in
standards that moot the most (or second most) important modern application of
DNSSEC. You keep talking about 9-10 million domains "presently signed", but,
as I keep pointing out, those were signed at registrars and are overwhelmingly
irrelevant zones. The point of the infographic is that zones people actually
care about --- not coincidentally, zones with giant, smart security teams ---
resolutely avoid DNSSEC.

~~~
ietf-dane
Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly...
I'll stop now and we'll both find something actually productive to do.

~~~
tptacek
They sure do! This one has taken (checks notes) 24 years.

