Saturday, 7 June 2014
RFC2616 is Dead
Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out.
Since 1999, it has served as the definition of HTTP/1.1, the protocol that underpins the Web. It’s 176 pages of everything from the definitions of GET, POST and DELETE to how TCP connections should be managed, and it was put together by the original HTTP Working Group over a few years in the mid-to-late 90’s, when it became apparent that the Web was going to be Big.
It turns out that it would become even bigger than was anticipated. People started using HTTP for things other than Web browsing (so-called “HTTP APIs”), and they began using the Web itself in new ways, with the advent of AJAX and later HTML5.
As a result, lots of questions started popping up about what the RFC means; since it was written for the “old” Web, lots of situations weren’t thought of, and needed clarification. And, like many consensus documents, it wasn’t clearly written down in some places, causing further confusion. This, in turn, caused people to interpret and implement HTTP in different ways, causing interoperability (and sometimes, security) problems.
Making It Better
So, in 2007, we started a new Working Group in the IETF called HTTPbis to improve the spec. Our charter was just to clarify, not to change it; we wanted to write the HTTP/1.1 specification down in a better way, not add new features or introduce a new version of the protocol.
Roy Fielding and Julian Reschke led the efforts as editors, splitting up the specifications into seven parts, later to be condensed into six. While doing so added to the page count (since a lot of boilerplate got repeated), it made the drafts easier to read, as it was more logically organised. The resulting specifications are:
- RFC7230 - HTTP/1.1: Message Syntax and Routing - low-level message parsing and connection management
- RFC7231 - HTTP/1.1: Semantics and Content - methods, status codes and headers
- RFC7232 - HTTP/1.1: Conditional Requests - e.g., If-Modified-Since
- RFC7233 - HTTP/1.1: Range Requests - getting partial content
- RFC7234 - HTTP/1.1: Caching - browser and intermediary caches
- RFC7235 - HTTP/1.1: Authentication - a framework for HTTP authentication
Along the way, we issued 26 draft versions, with over 2600 changsets, to address over 550 issues. Discussions of those issues brought in people from Open Source HTTP implementations like Apache, Curl, Squid, Traffic Server, HAProxy and Varnish, as well as people from companies that implement and use HTTP, from Microsoft and Apple to Yahoo! and Google.
What changed? Each RFC has “Changes from RFC 2616” section at its end, listing the major differences. We generally stuck to clarifying the text, although in some places we tightened things up where there was a serious security or interoperability issue. For example, folding a header across multiple lines is now deprecated, and the message parsing rules have been tightened up considerably to avoid attacks like HTTP response splitting.
Even where we just clarified, the changes are significant; for example, I edited the caching document, and ended up removing about ten pages of text, because 2616 said the same thing multiple times in slightly different ways!
These documents are now RFCs that collectively replace RFC2616, and should be referenced and used in its place.
Long Live HTTP
Seven years is a long time to work on a specification, even one as important as HTTP. While we knew it would take a while, we didn’t anticipate it taking this long, and the world has changed considerably since we started.
In particular, HTTP/2 is now nearing completion (which I’ll be writing more about soon). That’s OK; the new protocol actually needs much of the work we did to revise RFC2616. That’s because HTTP/2 only changes how the protocol’s semantics get expressed “on the wire”, as per the “Message Syntax and Routing” specification above. The rest of the specs we worked on for so long are very much needed by HTTP/2, and will likely also be used by HTTP/3, if we need it one day.
So, get familiar with the new-old HTTP/1.1; I’m happy to answer questions here, or you can ask them on the Working Group mailing list.