Fixing WebKit's Accept Header
WebKit has been on the forefront of web browser innovation for years, but their HTTP Accept header has lagged behind. (tl;dr it is fixed now.) The Accept header is how the web browser says to the web server "these are the content-types I can understand and the order in which I prefer them."
The Accept header allows a single object or resource to have a single URI with multiple representations, such as HTML, XML, or JSON. It is a fundamental component of the HTTP spec and REST style web services. Unfortunately, today's web services rarely use content-negotiation, because browsers have historically chosen bad Accept headers. WebKit's was the last serious offender:
application/xml,
application/xhtml+xml,
text/html;q=0.9,
text/plain;q=0.8,
image/png,
*/*;q=0.5
Parsed and prioritized:
1. application/xml
2. application/xhtml+xml
3. image/png
4. text/html
5. text/plain
6. */*
WebKit's Accept header preferred XML over HTML prior to my fix landing in trunk today. Web services could not offer both HTML and XML for a single resource and use content negotiation because WebKit based browsers (Safari, Chrome, et. al.) would be served the XML data not the HTML web page. Developers have had to hack around the issue. Twitter's API, for example, uses a common work around that changes the URI by appending a format extension.
http://api.twitter.com/version/statuses/friends_timeline.format
format ::= json | xml | rss | atom
The goal of the fix for WebKit's Accept header was straightforward: prefer HTML over XML. The ultimate solution was to minimize risk and take Firefox's lead. Here is the Accept header, already in order of preference, WebKit-based browsers will be using in the future:
text/html,
application/xhtml+xml,
application/xml;q=0.9,
*.*;q=0.8
Contributing to Open Source Software
The fix may have been committed today, but the initial bug report was filed in July 2009, almost two years ago! What took such a simple, but important, fix so long to be made? I would like to say it was the need for five other people to chime in on the ticket, someone on the WebKit team to notice, or a duplicate bug request to be filed 15,000 tickets later. But no, all the WebKit team needed was for someone, anyone, to submit a patch. So I checked out the subversion repository, made a patch, submitted it, and boom, I have contributed code to WebKit and fixed its Accept header woes. Very cool, but I feel horrible for not doing so with the original bug report in 2009; content negotiation would be more usable today.
Lesson learned: no matter how big or small an open source project is, when you find a bug and know the fix just do it. Do not assume code to be sacred or untouchable; just fix it and let the committers make the call. Bug reports are helpful, but patches and pull requests are gold. Discussions get read, code gets committed. Code speaks louder than words.