All the Perl that's Practical to Extract and Report
use Perl Log In
jk2addict (4946)
(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
Catalyst + REST
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
so frantically :-)
-- Jarkko Hietaniemi
Browsers suck (Score:2)
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
Re: (Score:1)
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).
Re: (Score:1)
This is a bug in Catalyst::Request::REST (Score:1)
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. ^^