WebKit-- # breaks Catalyst::Controller::REST

perigrin on 2009-02-21T23:17:06

WebKit is has a broken Accept header, it puts text/xml and application/xml first which breaks Catalyst::Action::REST’s default configuration and makes the idea of being able to dispatch html/xhtml different from XML difficult at best.

The reason it turns out is that the webkit developers cargo-culted from Firefox, and someone in 2007 provided a patch. The response to the patch is “buh buh Firefox is doing it!”. When I tried to add the comment below I discovered that their bugzilla required me to log in and didn’t appear to have an option for OpenID. Because I’m loath to create yet another account to file a single comment on a bug I’ve included the text here:

Firefox (3.1 beta 2 at least) is no longer sending this Accept headers.

Currently writing a REST-ful interface that renders XML different from XHTML/HTML at the same URI is difficult (requires us to browser sniff and do we really want to go back to that?) because Webkit based browsers will all send then wrong Accept headers first. I actually ran into this while writing an app that targets Android/iPhone and I had to disable my XML rendering code (luckily it was a stub and not a required feature).

Last the logic “Firefox does this” is a fallacy that I thought most people were taught better by their mothers at an early age … if Firefox were to jump off a bridge should WebKit too?


it would solve a lot of pain

rjw1 on 2009-02-21T23:49:21

and we could all go back to using lynx. just like god intended

Catalyst::Request::REST::ForBrowsers

autarch on 2009-02-22T03:26:10

You should take a look at this plugin. If it doesn't handle WebKit properly, patches would be welcome.

I've found it very handy when trying to write a RESTful app where the browser-side and API-side have the same URIs.