Why Revise HTTP?

By Mark Nottingham
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. 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.