Sunday, 9 December 2007
Why Revise HTTP?
I haven’t talked about it here much, but I’ve spent a fair amount of time over the last year and a half working with people in the IETF to get RFC2616 — the HTTP specification — revised.
That effort reached a milestone last week when the HTTPbis Working Group had its first face-to-face meeting in Vancouver. It’s still early days, but we’ve already made good progress; based on what we saw in the room, for example, it looks like Roy’s partitioned drafts will become the basis of the new work, and Roy, Julian and Yves will work together as editors on the new documents.
When I talk to people about this, however, I often get asked why we’re doing it. Revising HTTP certainly isn’t as sexy as coming up with another format or protocol for the world to adopt, and many people see what’s going on as boring, or not mattering to developers.
I couldn’t disagree more; this work must take place, and now is the best time.
HTTP started as a protocol just for browsers, and its task was fairly simple. Yes, persistent connections and ranged requests make things a bit more complex, but the use cases were relatively homogenous almost a decade ago, and the people doing the implementations were able to assure interop for those common cases.
Now, a new generation of developers are using HTTP for things that weren’t even thought of then; AJAX, Atom, CalDAV, “RESTful Web Services” and the like push the limits of what HTTP is and can do. The dark corners that weren’t looked at very closely in the rush to get RFC2616 out are now coming to light, and cleaning them up now will help these new uses, rather than encourage them to diverge in how they use HTTP.
So, while the focus of the WG is on implementors, to me that doesn’t must mean Apache, IIS, Mozilla, Squid and the like; it also means people using HTTP to build new protocols, like OAuth and Atom Publishing Protocol. It means people running large Web sites that use HTTP in not-so-typical ways.
Another reason to revise HTTP is that there’s a lot of things that the spec doesn’t say. The people who were there in the late 90’s understand the context, and those who have been around HTTP enough have learned to understand the thinking behind its design and the intent of its features. However, there’s a whole new generation of implementers and extension builders who haven’t been exposed to this. If we can document the philosophy of HTTP with regard to extensibility, error handling, etc., they have a better chance of understanding the right way to use it.
Last, but certainly not least, getting a bunch of HTTP implementers together and actively discussing the spec also leads to the possibility of interop work. While the IETF doesn’t do formal test suites, we can still come up with informal tools and a test corpus for improving interop.
In the end, my personal goal for this effort is fairly selfish; my job involves helping people inside my company understand how to use and extend HTTP in the best way possible. The current spec makes it very hard to do that, but a revision gives us the chance of improving the spec, people’s understanding of it, and how well it’s implemented.