On Mon, Nov 22, 2010 at 3:12 PM, Aristotle Pagaltzis <pagalt...@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@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/