Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jk2addict (4946)

jk2addict
  (email not shown publicly)
http://today.icantfocus.com/blog/
AOL IM: chrislaco (Add Buddy, Send Message)
Yahoo! ID: chrislaco@sbcglobal.net (Add User, Send Message)
Jabber: laco@scribblewerks.com

Journal of jk2addict (4946)

Thursday January 17, 2008
09:24 AM

Catalyst + REST

[ #35411 ]

Since we're on the topic of Catalyst and REST, I hereby declare Firefox 2.x broken.

There's this great set of modules under the moniker Catalyst::Action::REST that easily adds REST support to Catalyst. While I have no REST API in Mango (yet), I also use this package to do Content-Type -> View negotiations (text/html-> View::HTML, application/xhtml+xml->View::XHTML, application/atom+xml->View::Atom, etc), and it does it quite well.

Unfortunately, Firefox 2.x throws a kink in the works. The REST controller looks at the Content-Type header, then falls back to the content-type query param, then falls back to the Accept header. It's that last thing that kills. You see, firefox sends this accept header:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8, image/png,*/*;q=0.5

So, when I request a regular old web page, really wanting HTML, the REST controller negotiation falls back to text/xml, even though my default type in config is text/html. Grrr.

There are at least two solutions to this [for me in my base class]:

1. Cleanse the Accept header of this madness before calling the REST package into action

2. Map text/xml to my HTML View

Both are evil in their own ways. I started with #2, since people should really be sending application/xml anyhow and as of now, my app doesn't support xml via REST/content negotiation anyways.

#1 is really the better answer since we can't fix Firefox 2.x. For REST clients, they must send a Content-Type header, so those aren't a problem. And you can always override using the content-type param.

Just for giggles, Firefox 3.x beta Accept header is:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • IE7 doesn't say it accepts any form of HTML, but it _does_ accept "*/*". I'm using Catalyst::Action::REST as well but I've customized it so that if the request is a GET request and the request seems to be from a browser, I always return HTML. This can be overridden by setting a "content-type" query string param so that I can test manually from my browser.

    The way I determine if a request is from a browser is simply to check if an HTML type (text/html or application/xhtml+xml) is in the list of accepted conte
    • Now that I think about your response and the issue a little more, it seems even selecting text/html just because it's in the Accept is risky.

      I'd wager now, the best approach would be a config option to tell REST to ignore the Accept header altogether and instead go with the default type in config (even per controller).
    • Yeah, this is an unfortunate workaround for IE. At least Firefox gets it right. (Now, we just have to make Catalyst::Request::REST do the right thing ;-)
  • Check out RT bug #23772 [cpan.org]. The right solution to this is to let the server decide which of the highest-weighted Accept:'ed content-types to send.

    Of course IE breaks this by not even stating that it accepts text/html, but this is definitely not a Firefox bug.

    And Firefox 3.0's Accept headers look really sexeh to me. Definitive improvement. ^^