A New Definition of HTTP
Monday, 6 June 2022
Seven and a half years ago, I wrote that RFC2616 is dead, replaced by RFCs 7230-5.
Now, it’s those specifications’ turn to be retired. The RFC is dead; long live the RFC!
Why?
The emergence of HTTP/2 and now HTTP/3 have made it clear that HTTP’s “core” semantics don’t change between protocol versions. For example, methods and status codes mean the same thing no matter what version of the protocol you use; with a few exceptions, the same can be said about header fields.
However, RFC7231 entangled the definition of these core semantics with the specifics of HTTP/1.1. Given the progression of new protocol versions, the HTTP Working Group decided that it would be better to have a clear, generic defintion of the versionless semantics of HTTP separated from the individual wire protocols that people use.
That led us to rearrange HTTP into three documents:
- HTTP Semantics - those core, versionless semantics
- HTTP Caching - split into a separate document for convenience, but also versionless
- HTTP/1.1 - everything that’s specific to that textual wire protocol
The revision of HTTP/2 and the brand-new HTTP/3 (based upon QUIC) are being simultaneously published and both rely upon the first two documents.
What’s changed?
Beyond the refactoring described above, we also were able to address over 475 issues. Most of these were yet more clarifications of the text, but changes were also made to mitigate security and interoperability issues.
There were simplifications in terminology across the board (for example, we have a whole new set of terms to describe header and trailer fields), and a lot of rearrangement to make it easier to find relevant information.
HTTP field names now have their own registry to make them easier to track down. The operation of HTTP trailer fields was refined to make them more functional; time will tell if they get used more than they currently do.
In Caching, we made a number of updates to improve interoperability, including giving more nuance guidelines about how stored headers should be updated and refining how cache invalidation operates. Many of these changes were based on data we gathered from the HTTP caching tests.
All three documents also have summaries of the most important differences – all of the major changes are listed in HTTP Semantics, HTTP Caching and HTTP/1.1.
Will there be another revision?
Maybe. Both the Working Group and the editorial team really need a break.
However, I believe that when a protocol is important as HTTP, it needs constant maintenance and documentation improvements. Consider DNS in comparison; while there is interop in that community, that’s largely because there’s a group of “insiders” who know how the protocol really works, rather than good specification (although there are efforts to fix that, if only informally). Also, HTTP is implemented and directly used by a much broader community of developers.
History also indicates that if HTTP continues to serve people’s needs, we’ll need to refine and better document the corner cases as the protocol gets used for even more things and in new, interesting ways.
That means that you shouldn’t bother remembering the RFC numbers of the documents above; they only identify a version of the documents. The latest and most relevant HTTP specifications will always be listed on the HTTP Working Group Specifications page; I’d recommend using that as a starting point.
Thanks to my co-editors Roy and Julian, our Working Group chair Tommy, our Area Directors Francesca and Barry, and everyone who reviewed and commented on the documents; it’s been a lot of fun.