RFC 9114 – HTTP/3 | Hacker News Reader

RFC 9114 – HTTP/3

rfc-editor.org

156 pointsmfiguiere76 comments

Why does HTTP3 still support server push? When Chrome dropped it from their HTTP/2 implementation, I thought it was dead.

Cloudflare has also said they’re not implementing server push in their HTTP/3 support and will instead encourage Early Hints.

Co-chair of the QUIC WG here. Early in the process, we decided it was important that HTTP/3 provide parity with HTTP/2. That helps application developers to migrate back and forth between versions with less friction. So we include features of bidirectional stream multiplexing, request/response stream cancellation, server push, header compression, and graceful connection closure.

Some of those are more optional than others i.e. Server Push. Whether implementations choose to support a feature or not, at least the IETF maintain the close parity at the protocol level.

Stream prioritization is a different matter. That was very tricky in HTTP/3 [1], and through the process we designed Extensible Priorities, which is simpler and works over both H2 and H3. That was published today also as RFC 9218[2].

[1] https://blog.cloudflare.com/adopting-a-new-approach-to-http-...

[2] https://www.rfc-editor.org/info/rfc9218

Edit: typo fix

Dumb question/super out of the loop.

QUIC/HTTP2/HTTP3/whatever, are my options still only base64-encoded (in case of binary messages) server-side events and/or websockets, or is there some kind of bi-directional HTTP2/HTTP3 thing yet that's adoptable + usable?

It's more of a matter of libraries and implementations than of the standard. In ALL versions of HTTP, the request and response bodies are potentially infinite binary data streams. You can send a large file in them, but also e.g. lots of invidiual events with pauses in between (as e.g. utilized in gRPC streaming and for SSE).

However client and server libraries might not allow to access bodies as a stream, and would only provide a full response. That is e.g. the case for browser APIs, where the only APIs to access the response body either allowed to wait for the complete data to have arrived or allowed to parse SSE format. Newer APIs - e.g. fetch with ReadableStream [1] would lift some of those restrictions.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

I don't understand why server push is in the standard but not Early Hints.

I saw some articles but seems both server side & client side support are lacking.

(I can be wrong)

At least I don't see early hint in Nginx...

103 Early Hints is RFC 8297. It defines a status code. Because status codes are an HTTP semantic, they are common across all HTTP/1.1, HTTP/2, and HTTP/3. There's nothing special that needs to be done from a specification perspective, early hints _can_ work on any version. Whether implementations support that is a slightly different matter.

FYI early hints support is coming to Go, so it's possible that Caddy will gain support for it in a while (it'll need Caddy to have Go 1.19 as minimum so it's still like about a year or so away probably)

So the golang quic module will need to implement it .

I have been using quic with golang and am looking forward to trying this out

This is great! Despite how little the draft has changed over the last year, many communities seemed reluctant to work on an implementation until the RFC was published. Go definitely fell into this camp. Kudos to .NET for shipping HTTP/3 support in Kestrel already!

I have to say that I'm most excited for RFC 9110 (HTTP semantics), though :)

For the lazy:

https://www.rfc-editor.org/info/rfc9110

They killed the teapot!

https://www.rfc-editor.org/rfc/rfc9110.html#name-418-unused

They at least reserve 418 so that it won't get used for anything else.

But it looks like they don't list 451, defined in RFC 7725: https://datatracker.ietf.org/doc/html/rfc7725

We return 418 in a few places at work for endpoints that are only accessible to employees and you are not logged in. It’s a silly little Easter egg. Shame to see it going away.

Pretty sure you're supposed to return a 403 in any case. It'd be a nicer easter egg when sending some nonsensical but carefully chosen arguments to said endpoints.

Hmm, yeah, it's a 403 unless you are passing correct arguments but not logged in (which you'd only know if you were an employee or had access to the documentation).

Time for an RFC for HTTP 42 I’m a bowl of petunias.

I’d prefer HTTP 442 “Oh no, not again.”

Happy to see UDP being used here, because it means that networks that don't properly support UDP are now "broken."

There was for a time a risk that the Internet would become a HTTP-only network (at least at the endpoint) supporting TCP to port 80 and 443 and not a lot else.

Really. I've seen networks like this.

> the "http" scheme associates authority with the ability to receive TCP connections on the indicated port of whatever host is identified within the authority component. Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the authoritative server for a resource identified by an "http" URI

Was the possibility of using a different scheme (maybe http3 or h3) considered in addition to the altsvc mechansims?

Yes it was, there was a pretty lengthy discussion dating back to 2017 on the issue tracker https://github.com/quicwg/base-drafts/issues/253

TL;DR just like HTTP/2, we wanted to avoid friction in deploying these protocols. Having to rewrite URLs because of new schemes is pretty unpalatable, it has major impact. Instead, HTTP/3 can rely on other IETF-defined mechanisms like Alt-Svc (RFC 7838) and the more recent SVCB / HTTPS RR [1] DNS-based methods. The latter has been deployed on Cloudflare a while [2] and supported in Firefox. Other user agents have also expressed interest or intent to support it.

The net outcome is that developers can by and large focus on HTTP semantics, and let something a little further down the stack worry more about versions. Sometime devs will need to peek into that area, but not the majority.

[1] - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-... [2] - https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...

Am I the only one who finds the HTML rendered version[1] from the IETF site easier to read than the one from the rfc-editor site?

[1] https://datatracker.ietf.org/doc/html/rfc9114

Am I the only one who think there should be a "Am I the only one?" law named after some famous internet citizen who said something clever about "Am I the only one..." messages?

As one data point, I find https://www.rfc-editor.org/rfc/rfc9114.html easier on the eyes, mainly because of the font choice. I also like that I can link directly to titles (https://www.rfc-editor.org/rfc/rfc9114.html#name-other-schem...) where the title itself is visible in the URL rather than just the section-number (https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1.2) as if I'm participating in a discussion about the RFC and links are being thrown around, I can know which section is being referred to without opening the link.

But, I can also see how some people prefer the datatracker viewer. The only thing it's really missing is a Table of Contents as a sidebar so it's easier to navigate. Otherwise they are mostly the same.

Actually, it is that sidebar navigation which is one of the things bugging me, making the whole RFC harder to read. That said, when I'm implementing, I often refer to the text versions - especially as they're easier to diff.

As to ToC, that 9114 render seems particularly bad for some reason. Whereas this one does have a ToC with links:

https://datatracker.ietf.org/doc/html/rfc4128

That said, if I disable CSS (uMatrix) for the rfc-editor version, the ToC appears inline near the start, and looks a lot nicer. Possibly nicer then than the datatracker render.

I'm with you. I don't know who decided that RFCs should be displayed in a proportional font, but he was IMHO mistaken.

At least they are still available as plain text.

   Several characteristics of HTTP/3 provide an observer an opportunity
   to correlate actions of a single client or server over time.  These
   include the value of settings, the timing of reactions to stimulus,
   and the handling of any features that are controlled by settings.

    As far as these create observable differences in behavior, they could
   be used as a basis for fingerprinting a specific client.

   HTTP/3's preference for using a single QUIC connection allows
   correlation of a user's activity on a site.  Reusing connections for
   different origins allows for correlation of activity across those
   origins.

   Several features of QUIC solicit immediate responses and can be used
   by an endpoint to measure latency to their peer; this might have
   privacy implications in certain scenarios.

It feels like we've been moving backwards in terms of privacy since HTTP/2 even as those same privacy issues have been increasingly exploited by private companies and governments. It's sad to see the situation continuously worsened instead of being improved over time. It feels like a push for performance whatever the cost, or perhaps (more pessimistically) a push to degrade privacy and security while justifying it or distracting us from it with increased performance. It's strange to see security and privacy issues inherent to these specifications acknowledged, but not addressed.

As an end user, I already get satisfactory performance with the existing protcols. What slows things down is the neverending gratuitous Javascript and automatic connections not initiated by the user for the purposes of advertising, tracking and telemetry. Even viewing these RFCs in the best light, as "improvements", it stands to reason that end users will not be the ones who benefit most (if at all) from them. It is reminiscient of personal computers in decades past that kept increasing in speed and power only to have those increases usurped by gas-like software developed on the latest, most expensive workstations by software companies aiming to license newer versions, in some cases under agreements for pre-installation with OEMS aiming to sell newer hardware. "Gas-like" because over time it seemed to expand to fill available space. The newer PCs could do more, faster, behind the scenes, but the user experience did not change; for the user, it generally still took the same amount of time to do the same routine tasks. To put it another way, these "improvements" in well-established transport protocols may mean "tech" companies will be better able to exploit end users, e.g., more data collected and more advertising served without performance degradation, perhaps leading to more commerce, but not that end users will be better able to avoid exploitation, e.g. through improved privacy and security from "tech" companies and their advertiser customers.

> Even viewing these RFCs in the best light, as "improvements", it stands to reason that end users will not be the ones who benefit most (if at all) from them.

That's kind of how I see it. A lot of internet protocols have ended up having privacy and security issues, but not so much by design. We saw the problems introduced with HTTP/2 and it appears like we're just doubling down on them instead of trying to find solutions. I guess I'm just nostalgic for the days things were made to benefit internet users rather than the people looking to make money off of them.

For what it's worth, the HTTP/2 specification contains almost identical phrasing as HTTP/3 [1]. That's not unexpected, the considerations are similar: using a single connection with connection-specific values has potential implications. However, the possibility for fingerprinting is inherent in every protocol and HTTP semantics itself paints out the ways common features might get used.

Considerations are just that. Choices in light of considerations can be traded off by client implementations - they can make their own choices about how to address these matters.

The work in the IETF to define oblivious DNS and oblivious HTTP [2] protocols is a step towards reducing such surfaces, at the trade off of functionality.

[1] https://www.rfc-editor.org/rfc/rfc9113.html#section-10.8 [2] https://datatracker.ietf.org/wg/ohai/about/

Doesn't it make more sense to separate concerns? Build the highest performance protocol possible that can operate efficiently under a wide array of conditions and then route via an overlay such as i2p whose sole job is to provide privacy if you want to do that.

Also isn't an implementation free to avoid things like connection reuse if it so chooses? For that matter some browsers support fully containerizing things per site visited.

> Doesn't it make more sense to separate concerns?

Wouldn't it be better to design a protocol that doesn't have those concerns in the first place? A good design would be easy to implement without opening up users to security and privacy issues. Designing something insecure and/or harmful and then saying that it's the implementer's job to figure out a way to fix the mess you just made feels wrong to me.

> Wouldn't it be better to design a protocol that doesn't have those concerns in the first place?

I'm referring to design concerns, not usage concerns. To minimize privacy concerns related to usage, you first have to add privacy as an additional design concern.

And privacy is a particularly difficult one because it means a lot of different things to different people. Can you reuse connections at all? What about content fingerprinting based on transfer rates - do you need to add cover traffic? Voice codecs, for example, will inadvertently reveal when the stream goes silent because they more or less stop transferring data. Instead of designing voice codecs to be less efficient, it probably makes more sense to optimize them to the maximum extent possible and then handle privacy concerns at a higher layer on an as-needed basis.

Separating design concerns to the extent reasonably possible tends to yield significantly less complex end results which has a whole host of benefits. A Swiss army knife often proves to be sub par in practice when compared to more specialized tools. Do one thing and do it well.

> A good design would be easy to implement without opening up users to security and privacy issues.

Simple designs are nearly always easier to implement. Compare the code base of OpenVPN to WireGuard for example. I think it's quite reasonable for a spec to accommodate implementations that want to make various optimizations that sacrifice user privacy. In cases where that's a concern implementations can omit such optimizations as necessary based on their specific usecase.

> To minimize privacy concerns related to usage, you first have to add privacy as an additional design concern.

I suppose I would argue that privacy and security should be a design concern. Not that it should necessarily be an issue for every protocol, but certainly for anything intended to widely replace something like HTTP or other very common internet protocols.

> I think it's quite reasonable for a spec to accommodate implementations that want to make various optimizations that sacrifice user privacy.

Sometimes it really is enough just to know that something is extremely fragile, or insecure, or easy to exploit. People can decide for themselves if they want to use it or not according to their needs. I have written a large number of programs for my own personal use where I made the intentional decision to neglect security. Because only I use them, and I know what the dangers are, and only I control the inputs it's not really an issue.

In some situations/environments there are still valid uses for older protocols like FTP even though more secure options now exist, but certainly if a new version of FTP was being designed I would expect it to try to correct the known issues with past versions.

It's not really a problem if Google designs QUIC to allow users to be tracked anywhere they go on the internet and it makes services vulnerable to DoS attacks. It's much more of a problem when those problems become part of HTTP and users who disable or refuse to accept HTTP/3 connections for their own protection are at risk of being cut off from large swaths of the www.

I assume security is a concern already. Privacy's just less well defined and a lot harder. Connection fingerprinting is hard and I don't really think it's worth trying to solve for HTTP because... they're not going to.

If you want anonymous browsing, use TOR. If you say "well TOR is too slow", welcome to the HTTP/3 party.

> Voice codecs, for example, will inadvertently reveal when the stream goes silent because they more or less stop transferring data.

Secure audio transports don't do this for what it's worth. They use Constant Bit Rate encodings. A constant number of bits are consumed every period regardless of whether there's silence. For example if you make a voice call with Signal it uses Opus CBR, an adversary suitably placed on your network path can see how long your call was, but they cannot measure silence.

With a Variable Bit Rate encoding it is possible for an adversary to not only detect silence but also estimate whether you said certain key things. For example if there's a "Project Amadeus" and you've got all the encrypted voice calls between dozens of people using a VBR codec you could write software which sifts those calls to find those which seem likely to mention "Project Amadeus" based on the data rates.

> This document describes a mapping of HTTP semantics over QUIC.

Hooray!

It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport. That HTTP can express itself in terms of another spec is one of the most compelling, longest-hardest won & best victories for "abstraction" that computing has seen. That we'll be able to iterate on HTTP in new ways, by having a common semantic base, keeps the future open & iterable. Huge wins.

Obligatory link to Mark Nottingham's "A New Definition of HTTP3"[1], which talks about the split of HTTP into a semantic definition in RFC9110[2] & the creation of HTTP2/RFC9113 and HTTP3 (over QUIC, this document).

[1] https://www.mnot.net/blog/2022/06/06/http-core https://news.ycombinator.com/item?id=31647149 (3 points, 26m ago, 0 comments)

[2] "HTTP Semantics" https://www.rfc-editor.org/rfc/rfc9110

[3] "HTTP2" https://www.rfc-editor.org/rfc/rfc9113

> It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport.

That's what I thought too. A while ago, I wanted to use it in an Android app. I thought this was going to be a no-brainer. After all, Google more or less invented QUIC as SPDY about a decade ago. To my understanding, since they just YOLO'd it they agreed to form a proper working group and create quic. So here we are, ten years later, Google is heavily using quic for all their web stuff, and I naively assumed that Android would've had a native quic implementation for a while now, either directly in the SDK/runtime, or some first party library from Google. Nada. There is cronet, the networking engine of chrome as a library, which does speak quic but only exposes classes and functions to speak http, so you cannot even use its quic implementation directly. I went on and had to use some C library and JNI to do it, which is just ridiculous.

Sorry for this tangentially related vent, I'm still in disbelief.

Note that even the previous draft specification (https://datatracker.ietf.org/doc/draft-ietf-quic-http/34/) was a mapping of HTTP semantics on top of QUIC. It didn't carry too many transport specific concerns - which e.g. HTTP/2 did, since it cared about flow control and other things.

I have yet to read RFC 9114, but I guess it's refinded to fit better on top of the new HTTP semantics spec (RFC 9110).

I'd be aghast to see a significant rewrite of a specification as it moves from draft to rfc. The draft, at it's end, should closely mirror the final spec.

I'm a little surprised they kept http push, since early hints is often a better solution and browsers don't support server push.

They explain why above: https://news.ycombinator.com/item?id=31648565

I started writing this before, the above question was posted.

You know what http needs? Built in port location as part of the protocol... preferably via DNS.

What use cases are you thinking of? As far as I can see, the main and perhaps only use case is hosting websites behind ISPs which block the default ports. Although since http is leaving TCP, I wonder if these blocks will continue to work.

One would be IP address assignment proliferation due to containers and shared services. SNI only goes part of the way to reducing the demand, being limited because it can't cross administrative trust boundaries. For v4 this is an ongoing exhaustion issue, but even for v6 it's an ops and allocation problem.

Imagine if, for example, public clouds didn't need to burn a separate address for every dynamically provisioned load balancer.

Http to https (and maybe naked to www) upgrades specified in DNS instead of requiring redirects?

Don't we already have this problem solved via HSTS and particularly the preloaded list? Which is even more secure than doing it via DNS.

Only after an initial request

Do you mean something like the existing SRV records, or something else?

Do web browsers look to SRV records with its port field in preference to A records?

SRV records already exist.

Yes, but their use isn't defined for HTTP, and browsers don't support using SRV records for resolution.

A records aren't defined either.

Indeed, but the SRV resords spec states that they shouldn't be used where the protocol in question doesn't specify their use:

"In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification."

-- RFC 2782

It really doesn't.

It really does, but it also already has it via RFC7838 (HTTP Alternative Services / ALTSVC), which is normative for HTTP/3¹, albeit an optional client behaviour. Unfortunately not via DNS; you still have to run the origin on a well-known port if not specified in the URI. Clients supporting ALTSVC are then defined to use them at a requirement level of "should"².

[1] https://datatracker.ietf.org/doc/html/rfc9114#section-3.1.1

[2] https://datatracker.ietf.org/doc/html/rfc7838#section-2.4

So was it really worth it to make it so damn complicated and put it out of range for most developers and existing programs in terms of implementation effort, sidestepping IP networking even, for actual hypertext transport when the web is contracting as we speak? Ignoring incidental use of HTTP for "REST APIs" (an oxymoron in itself).

It's nice to have progress in some areas.

However, I'm disappointed to observe that we're on to version 3 and the HTTP editors are still writing tortured thickets of handwaving cross-references to avoid specifying which DNS records it uses.

Instead, HTTP continues to refer normatively to the http(s) URIs, which eventually confess:

"This specification does not mandate a particular registered name lookup technology".

and then everyone squats the A/AAAA address records by default, effectively denying them for any other purpose. There are some obvious consequential misbehaviours (such as the perennial "apex record" problem), but more broadly, HTTP subverts the DNS by de facto appropriating potentially all labels, and continuing to do so represents a middle finger in the face of every other protocol designer. This situation gets more rusted-on and harder to figure out remediation with each revision, and there's a lesson or two in here for anyone who develops protocols for a living.

There’s a lesson or two in understanding and respecting the difference between the two technologies you’re discussing.

www.example.com. A 192.0.2.1, for example, will work for both HTTP and SSH and whatever else you want to put there. If you have SSH on 22/tcp and HTTP on 80/tcp and HTTP over TLS on 443/tcp, all of those are reachable via the same exact A record in DNS without even clarifying what port you intend. Plain “ssh www.example.com” would work just fine.

That’s why your statements about subversion of the DNS and squatting on DNS RR types show you to not understand what you’re dealing with, which makes your emotional state about it even more discouraging. You seem to be upset that HTTP has a well-known port. That’s the only sense I can make from what you’re saying, anyway, because you’re ranting at something you seem to have an extremely loose grip on understanding. Hundreds, if not thousands, of protocols start their life with gethostbyname, which looks at A/AAAA. That’s not unique to HTTP and, more importantly, doesn’t deny the A and AAAA RRs for any other purpose. Your gripe makes no sense.

The apex record problem has to do with the DNS specification and the behavior of CNAMEs. It was an issue before the Web existed (crazy, right?). I sense that your career has primarily been involved with DNS as an enabling mechanism for HTTP systems, probably mostly working with virtual DNS hosts like VIPs (given that you incorrectly distinguish “hosts” from the apparent squatting you’re observing in another comment) and you have next to zero context on how very different they are and how little they have to do with each other.

Before you start accusing people of middle fingers and such, you might want to put aside your rage and question yourself: do I fully understand what I’m mad about?

Welcome back, rosndo.

I don’t understand. What has DNS got to do with HTTP? If I connect to http://foobar.onion/ it’s not using DNS, isn’t that what they mean by “not requiring a particular lookup technology”?

And what is the issue with A/AAAA records exactly?

This is pointless hairsplitting. RFC7686 is a DNS RFC, one that specifies and enables special application handling when stipulated conditions are met. Even if HTTP/3 defined its use of DNS records adequately, the special case still takes precedence and onion routing continues to occur in browsers supporting it.

In my view the use of a special-case TLD is deeply problematic since it contains the potential to leak your use of Tor via applications or resolvers that do not grok the exception, but that's a design problem for another day.

The problems with using host address records for service location are multifaceted but the most significant are a) their conflict with other services at the same label, most commonly when the web hosting requires a CNAME, which cannot co-exist with any other record, and b) they're crude; full-grown origin discovery could support priorities, fallbacks, protocol upgrades, variation by transport, alternate ports and more besides.

I assume the parent was hoping for SRV record support.

SRV is a probably a smidgen shy of what HTTP needs in 2022, although if the protocol were invented today it’d be a shoo-in for resolution in the common case.

Doesn't SSH "subvert DNS" just as much, as it also relies on A/AAAA records when you type in `ssh user@fqdn.`? Or `ping fqdn.`, for that matter?

No. Firstly, SSH is not used at the scale where any such misuse might be a problem. Secondly, SSH is used for connecting to specific hosts, which is what the A/AAAA records actually are (being by definition the host address).

So what's the problem then?

Are you somehow thinking that if you have a web server serving HTTP traffic on a server, you need a different A record to connect to it with SSH? Because that is very much not how it works.

Historically, isn't this what the "www" prefix to a URL is for? www.example.com for HTTP, ftp.example.com for ftp, &c.

Yeah and news/mail/telnet/irc. Not very common nowadays of course, although www still hangs around.

Mail has had MX records for a while, but yes for the rest.

More like ftp://example.com ?

The “ftp://“ is a protocol/scheme and not part of the domain’s definition, hinting that the client should connect to port 21 of the A record. With a put ftp client, defining the scheme/protocol is not necessary.

> and then everyone squats the A/AAAA address records by default, effectively denying them for any other purpose.

Can you clearly and lucidly explain what you mean here? How is HTTP "denying" A records from pointing people to servers being used for other protocols?

Reply on news.ycombinator.com