Ask HN: Why would anyone POST anything in AJAX?

https://news.ycombinator.com/item?id=568686

by mlLK • 17 years ago

12 30 17 years ago

news.ycombinator.com

Bear with me here because I'm bound to take you off tangent, but as I've been developing more and more server-side oriented applications for HTTP I find myself pondering the advantages and disadvantages of implementation; so this may come across as an answer rather than a question. But wasn't AJAX created as a work-around for POST? Correct me if I'm wrong but POST is primarily a method for the server not the client, while GET behaves more like the web today (2.0) in that users spend more time requesting stuff (an xhr that passes some value who in turn returns with a response) from a server rather than writing or executing stuff on that server.

If anything AJAX seems like it was made especially for GET to cut-down on how much and what was being passed with POST...I might be way off, but does it not seem contradictory to POST something in AJAX without returning a response?

aristus• 17 years ago

Not at all. Imagine a document editor. There are limits to the amount of data that can be passed via GET URLs. Without POST you could only have 2KB documents. In Archivd we use POST via Ajax anywhere the user mutates data. It avoids the data length problem and makes it simpler to defend against CSRF attacks.

mlLK2• 17 years ago

Imagine a document editor.

For the web? Passing the entire document asynchronously?

In Archivd we use POST via Ajax anywhere the user mutates data.

See, I'm still new to AJAX and from the type of apps that I use and experiment with are generally broken down as independent events who pass values and who perform an xhr as each event is triggered. I guess as your app grows and the data your handling using this methodology (as GET) is suddenly just too complex to carry out on the client. Thanks for the input though.

boucher• 17 years ago

280 Slides uses an asynchronous POST (or PUT) request for saving documents.

Just because the mechanism for generating requests has changed, that doesn't mean the mechanics of REST should be thrown out the window.

REST is useful, and its how most of the infrastructure of the web works. It's useful to understand this, and try to build your applications appropriately.

intranation• 17 years ago

> For the web? Passing the entire document asynchronously?

See Google Docs as an example of this.

drawkbox• 17 years ago

Ok even if you do independent events eventually you want to upload an image or a file which is not going to fit in GET very well, the url path is limited to 2k.

POST you can pass much more information, also it is more secure in that is does not log the params and path in logs.

Or maybe you POST to a REST url that has some params such as an api_key, then you post the data structure. Or you want to post a large JSON object of all data on a page. Again limits to GET, so people choose POST then. It depends on the situation.

bluefish2• 17 years ago

Using POST doesn't necessarily make it simpler to defend against CSRF. You still need to use some kind of exclusive token shared between the client and server (e.g. a session id stored in a cookie). Imagine a poorly implemented site that doesn't prevent users from uploading js script blocks into the comments. A user could upload a script that creates a form and submits it via POST to your POST restricted endpoint, thus circumventing POST only protection. I'm assuming I've misread your comment as you use POST only and you're also doing proper CSRF protection right?

cperciva3• 17 years ago

Many systems have limits on the maximum length of a GET query string, since said strings form part of a URL. In most cases these limits are quite large (4kB or more) but I've seen systems which can't even handle 1kB URLs.

If you want to send a large amount of form data and not have things randomly break, it's a good idea to use POST instead of GET.

jamroom• 17 years ago

Internet Explorer has problems with URLs over 2047 characters in length - if you are needing to handle large amounts of text (say from a textarea), POST is the way to go.

jaxn• 17 years ago

In addition to request size limits, using the HTTP methods on server side code can simplify code. If I GET a person record then send it down, if I POST a person record then process the passed parameters. With that separation I may find that POST requests do not require sending any data to the client (other than a success indicator). That reduces bandwidth and improves client response time.

I have really grown to appreciate this simplification while working with webpy on AppEngine. I think that my request handlers are about the cleanest they have ever been.

pmjordan7• 17 years 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.

mlLK2• 17 years ago

Awesome. 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• 17 years 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• 17 years ago

With 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.

pmjordan7• 17 years ago

Thanks for raising the form issue. Presumably this can be done surreptitiously in a hidden iframe? (submitting a form normally displays the response)

jeremyawon3• 17 years ago

for 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.

cperciva3• 17 years ago

First 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).

pmjordan7• 17 years ago

Thanks for correcting the definition of idempotence in my brain! (edited original post)

jon_dahl• 17 years ago

PUT 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?

gills• 17 years ago

I use ajax POSTs for autosaves, creating and deleting 'child' objects (when the UI for the sub-object should be added to/removed from the page without a reload). Basically any mutation where I don't want a reload.

cnlwsu• 17 years ago

POST easier to protect from XSS attacks when using the Django middleware.

jim_lawless• 17 years ago

GET parameters can ( and often do ) show up in web-server logs. Transmitting sensitive data via a GET ( even over SSL ) may ultimately cause security / privacy concerns.

Ask HN: Why would anyone POST anything in AJAX?

Related Stories