4 ms·
In addition to tzs' comment above, POST parameters do not get logged by the web server either (default Apache logging, etc), unless you're using a module like m
by marcinw 16y ago
In addition to tzs' comment above, POST parameters do not get logged by the web server either (default Apache logging, etc), unless you're using a module like mod_security to log POST data.
Besides, don't use GET for non-idempotent requests (those which change state). That's just webapp development 101.
Edited for clarity.
- axiak 16y agoEither I'm completely misunderstanding your grammar, or you don't understand what idempotent means... idempotent and state-changing are almost opposites.
- fhars 16y agoYou don't understand what idempotent means. An action is idempotent if repeating it does not change the result. For example, multiplying by zero is idempotent, 0 * x is the same as 0 * 0 * 0 * 0 * x. But of course it changes something, as 0 * x is clearly not x in the general case. In the http case, GET and HEAD should not change any state (be safe and idempotent), PUT and DELETE should change state but be idempotent, and POST can do whatever it wants. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
- axiak 16y agoMaybe you saw the text after @marcinw changed his text? I agree with you, of course I will say that most http GET actions I see are trivially idempotent -- that is to say they are idempotent because they don't change the state at all.
- fhars 16y agoNo, I saw the original version that cautioned against state changing idempotent GET requests. The changed version is actually worse, as it only cautions against non-idempotent GETs, which is not enough. State changing idempotent requests via GET are quite as bad. In fact, idempotency is irrelevant for GET, as GET requests should be safe, which trivially implies that they are idempotent. So requiring idempotency in addition to safety does nothing except making the prose harder to read.
- pyre 16y agoThese comments seem at odds: > GET and HEAD should not change any state > (be safe and idempotent) > But of course it changes something, as > 0 * x is clearly not x in the general case. If 0 * x is idempotent, but it changes things then how can 'should not change state' be equivalent to idempotent? If I use a GET request to submit a shopping cart (for example), as long as submitting that URL a second time doesn't placee a second order for a copy of the original shopping cart (maybe it has a unique identifier so the backend can tell that it's already been submitted), then that should be idempotent, right?
- bobfunk 16y agoUsing GET to submit a shopping cart can be "idempotent", but it is not "safe" since it changes state on the server. GET should always be both safe and idempotent.
- wahnfrieden 16y agoRight, but the idempotence is a side effect of the safety here. It's not the main point.
- marcinw 16y agoSorry for the confusion, I meant "non-idempotent". I had two separate thoughts in my head at once and munged the two, leaving out the "non-".
- fhars 16y agoSorry, but your "correction" made your statement even more inaccurate. You should have elided the scary latin "idempotent" and kept "state changing", as the latter is what GET requests must avoid. GET http://example.com/index?action=delete;recursive=true http://example.com/index?action=delete;recursive=true is idempotent, but usually not what you want to see in action on your site...