Manual Reference Pages - CATALYST::TRAITFOR::REQUEST::REST::FORBROWSERS (3)
Catalyst::TraitFor::Request::REST::ForBrowsers - A request trait for REST and browsers
Writing REST-y apps is a good thing, but if youre also trying to support web
browsers, youre 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,
its really not going to do anything useful with it, and youre 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
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:
This all works well for my apps, but read it carefully to make sure it meets
your expectations before using it.
If the request includes a header X-Request-With set to either HTTP.Request
or XMLHttpRequest, this returns false. The assumption is that if youre
doing XHR, you dont want the request treated as if it comes from a browser.
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 browser.
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 */*. IE7s Accept header does not include any html types
If the client provides an Accept header and accepts either text/html or
application/xhtml+xml it is a browser.
If it provides an Accept header of any sort that doesnt match one of the
above criteria, it is not a browser.
The default is that the client is a browser.
Dave Rolsky, <email@example.com>
Please report any bugs or feature requests to
firstname.lastname@example.org, or through the web interface at
<http://rt.cpan.org>. We will be notified, and then youll automatically be
notified of progress on your bug as I make changes.
COPYRIGHT & LICENSE
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.20.3 ||CATALYST::TRAITFOR::REQUEST::REST::FORBROWSERS (3) ||2015-10-29 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.