5 ms·
There are numerous implications of choosing POST or GET. First off, the HTTP specification requires that GET (and HEAD) requests be idempotent^W EDIT: side eff
by pmjordan 18y ago
There are numerous implications of choosing POST or GET.
First off, the HTTP specification requires that GET (and HEAD) requests be idempotent^W EDIT: side effect free to enable caching. Clearly, violations of this abound; however, proxy servers and other infrastructure will often hold you to this rule, so make sure you know what you're doing. (proxies and clients are permitted to withhold or arbitrarily repeat GET requests without changing the outcome)
Second, security: although AJAX in the strictest sense falls under the same-origin policy, you can quite easily make GET requests to foreign hosts in JavaScript by creating SCRIPT, IMG or IFRAME elements with appropriate SRC attributes, whereas you'll struggle to create a foreign-host POST. Inappropriate use of GET is therefore the enabler of XSRF attacks. CAUTION: read petewarden's reply regarding XSRF attacks via POST forms.
Third, data size, as others have said. URLs are notoriously problematic for conveying any information other than short text.
Fourth, if web crawlers get hold of any URLs which exhibit side effects on GET, they will wreak havoc on your site. (though this can admittedly be alleviated by judicious use of robots.txt)
Finally, you seem to imply that POST requests will not or cannot generate a response similar to GET. This is not the case, responses to POST work in the same way. (except it must not be cached) The deciding factor is the nature of the request (side effect or no side effect), not the nature of the response.
- mlLK 18y agoAwesome. 5 things I now know that I probably would have not known for years to come by making mistakes. Without a whole lot of experience with AJAX + that nagging feeling I'm implementing it wrong, it's practical rules like these that I can easily put into practice. Finally, you seem to imply that POST requests will not or cannot generate a response similar to GET. This is not the case, responses to POST work in the same way. (except it must not be cached) The deciding factor is the nature of the request (side effect or no side effect), not the nature of the response. Yah I actually found this out right after I posted and had I known the difference between an AJAX POST and an AJAX GET was literally like 5 to 10 lines of code I may have never asked such an ostentatious question.
- mark-t 18y ago> Fourth, if web crawlers get hold of any URLs which exhibit side effects on GET, they will wreak havoc on your site. Web accelerators, too, and those will not be controlled by robots.txt. I would definitely advise the OP to read the HTTP spec about the differences between POST and GET, or perhaps an introduction to RESTful web development.
- petewarden 18y agoWith regards to point #2, it's definitely inconvenient to cross-site POST from the client side, but not hard: Create a form with a target pointing to the external destination and submit it via Javascript, wrap it inside an invisible frame for neatness. Don't let POST give you a false sense of security; checking the referrer can help in this particular case (it's tricky to forge the referrer from the client side) but you really need a robust check like a generated token to avoid malicious cross-site requests.
- pmjordan 18y agoThanks for raising the form issue. Presumably this can be done surreptitiously in a hidden iframe? (submitting a form normally displays the response)
- jeremyawon 18y agofor what it might be worth to others: i've generally found that the client already has a cookie-session established in situations where cross-site ajax calls are a concern. so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature.
- pmjordan 18y agoThat's a pretty clever and elegant way to handle it, and seems to be pretty universally applicable, thanks!
- bluefish 18y agoThis is also known as Cross Site Request Forgery or CSRF: http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery
- anamax 18y ago> so, my approach is to require a hash of <request text>+<session id cookie> as a per-call signature. javascript on another domain can't access the session id cookie and so won't be able to generate this signature. If the security relies on other javascript not being able to access the session cookie, why is it insecure to use said session cookie by itself as the per-call signature? Who can see the signature but not the session id cookie?
- cperciva 18y agoFirst off, the HTTP specification requires that GET (and HEAD) requests be idempotent to enable caching. Technically, PUT request are supposed to be idempotent, while GET and HEAD are supposed to be side-effect free (which is strictly stronger than idempotency).
- pmjordan 18y agoThanks for correcting the definition of idempotence in my brain! (edited original post)
- jon_dahl 18y agoPUT is supposed to be idempotent? So an "increment" or "reverse" request should technically be a POST? Or does the idempoten-cy apply only to the response from the server, and not the state of the data on the server?
- pmjordan 18y agoThat's certainly my understanding of it. PUT has semantics of resource creation or updating, like writing a file: whatever you upload replaces what is already there, if anything. You can process the data of course, but the outcome should depend only on the request data itself, not state.
- cperciva 18y agoPUT is supposed to be idempotent? So an "increment" or "reverse" request should technically be a POST? Absolutely. User-agents are allowed to retry PUTs transparently -- it's only for POSTs that they're supposed to put up a "are you sure you want to re-submit this form? Bad stuff might happen" dialog.