[Catalyst] Re: Converting a GET request to a POST request

Sam Kaufman samuel.c.kaufman at gmail.com
Thu Nov 25 20:16:15 GMT 2010

I proposed a solution, the package Resty::Controller::API; example I
sent earlier. Trying to write your controller using
Catalyst::Action::Deserialize is a mistake, as it's not what
Deserialize does.
from http://search.cpan.org/~bobtfish/Catalyst-Action-REST-0.87/lib/Catalyst/Action/Deserialize.pm

"This action will deserialize HTTP POST, PUT, and OPTIONS requests. It
assumes that the body of the HTTP Request is a serialized object. The
serializer is selected by introspecting the requests content-type

You want to deserialize a GET request. GET requests have no body. GET
requests generated by <script src> tags request content-type "*/*". So
the correct way to code this would be handle it as what it is, a GET
request with a parameter that's JSON encoded, for which you can use
something like the example I provided earlier or just a regular
controller with a base that decodes the encoded parameter and does
what you want.

On Tue, Nov 23, 2010 at 11:56 AM, Ronald J Kimball
<rkimball at pangeamedia.com> wrote:
> On Mon, Nov 22, 2010 at 3:12 PM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:
>> This is really, really, really bad. It’s roughly like modifying
>> a file system to be allow file deletion as a side effect of
>> opening a file. GET is supposed to be safe, that is, it should be
>> free of side effects that the user cannot be held responsible
>> for. It is very, very easy to get a browser to send GET requests
>> incidentally, eg. by putting the link in a `<img src>` or
>> a stylesheet `<link>` and getting a user to visit. Things like
>> Google Web Accelerator and other automated user agents (like
>> search engines of course) also generally assume that GET is safe.
>> Much web infrastructure also assumes that GET requests are
>> cacheable, so if there are any proxies between the app and the
>> user, sending multiple pseudo-POST requests may not actually do
>> anything.
> I completely understand the points you're making here.  As I said, one
> of the drawbacks of this solution is that it makes me feel really
> dirty.
> For what it's worth, the REST methods that I want to expose in this
> way are for posting responses to content.  There won't be any deletes.
>> The same-origin policy is not there by mistake, but to keep your
>> users safe from malicious 3rd party sites they may visit.
> REST principles dictate that I use POST, not GET, for these requests.
> The same-origin policy forces me to use JSONP, which can only make GET
> requests, not POST.  What's the solution?
> Ronald
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

More information about the Catalyst mailing list