Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help

       Catalyst::TraitFor::Request::REST::ForBrowsers -	A request trait	for
       REST and	browsers

	   package MyApp;
	   use Moose;
	   use namespace::autoclean;

	   use Catalyst;
	   use CatalystX::RoleApplicator;

	   extends 'Catalyst';


       Writing REST-y apps is a	good thing, but	if you're also trying to
       support web browsers, you're probably going to need some	hackish
       workarounds. This module	provides those workarounds for you.

       Specifically, it	lets you do two	things.	First, it lets you "tunnel"
       PUT and DELETE requests across a	POST, since most browsers do not
       support PUT or DELETE actions (as of early 2009,	at least).

       Second, it provides a heuristic to check	if the client is a web
       browser,	regardless of what content types it claims to accept. The
       reason for this is that while a browser might claim to accept the
       "application/xml" content type, it's really not going to	do anything
       useful with it, and you're best off giving it HTML.

       This class provides the following methods:

       This method works just like "Catalyst::Request->method()" except	it
       allows for tunneling of PUT and DELETE requests via a POST.

       Specifically, you can provide a form element named "x-tunneled-method"
       which can override the request method for a POST. This only works for a
       POST, not a GET.

       You can also use	a header named "x-http-method-override"	instead
       (Google uses this header	for its	APIs).

       This attribute provides a heuristic to determine	whether	or not the
       request appears to come from a browser. You can use this	however	you
       want. I usually use it to determine whether or not to give the client a
       full HTML page or some sort of serialized data.

       This is a heuristic, and	like any heuristic, it is probably wrong
       sometimes. Here is how it works:

       o   If the request includes a header "X-Request-With" set to either
	   "HTTP.Request" or "XMLHttpRequest", this returns false. The
	   assumption is that if you're	doing XHR, you don't want the request
	   treated as if it comes from a browser.

       o   If the client makes a GET request with a query string parameter
	   "content-type", and that type is not	an HTML	type, it is not	a

       o   If the client provides an Accept header which includes "*/*"	as an
	   accepted content type, the client is	a browser. Specifically, it is
	   IE7,	which submits an Accept	header of "*/*". IE7's Accept header
	   does	not include any	html types like	"text/html".

       o   If the client provides an Accept header and accepts either
	   "text/html" or "application/xhtml+xml" it is	a browser.

       o   If it provides an Accept header of any sort that doesn't match one
	   of the above	criteria, it is	not a browser.

       o   The default is that the client is a browser.

       This all	works well for my apps,	but read it carefully to make sure it
       meets your expectations before using it.

       Dave Rolsky, "<>"

       Please report any bugs or feature requests to
       "", or through the web interface at
       <>. We	will be	notified, and then you'll
       automatically be	notified of progress on	your bug as I make changes.

       Copyright 2008-2010 Dave	Rolsky,	All Rights Reserved.

       This program is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

perl v5.32.1		     Catalyst::TraitFor::Request::REST::ForBrowsers(3)


Want to link to this manual page? Use this URL:

home | help