[Catalyst] Re: Converting a GET request to a POST request
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
"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
> 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
> 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?
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://email@example.com/
> Dev site: http://dev.catalyst.perl.org/
More information about the Catalyst