Doctorow: The Curious Case of Internet Privacy (Technology Review) [LWN.net]

Doctorow: The Curious Case of Internet Privacy (Technology Review)

Posted Jun 7, 2012 21:49 UTC (Thu) by dlang (✭ supporter ✭, #313)
In reply to: Doctorow: The Curious Case of Internet Privacy (Technology Review) by bjartur
Parent article: Doctorow: The Curious Case of Internet Privacy (Technology Review)

that would break many sites. not all server-side changes (and thus changes that are relevant to cookie changes) result from posts.

A large part of the REST fad is based on eliminating posts (and ideally cookies as well, but posts first)

(Log in to post comments)

Doctorow: The Curious Case of Internet Privacy (Technology Review)

Posted Jun 8, 2012 2:50 UTC (Fri) by bjartur (subscriber, #67801) [Link]

Not necessarily all POSTs. Don't go around replacing POST forms with GET ones, unless you understand that GET ones SHOULD NOT have the significance of taking an action other than retrieval.

PUT is, however sadly,
   supported so badly
   in HTML and others
   that no-one bothers.

Doctorow: The Curious Case of Internet Privacy (Technology Review)

Posted Jun 8, 2012 3:08 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

more precisely, a browser is allowed to re-send a GET at any time, that doesn't mean that it can't have an effect.

Doctorow: The Curious Case of Internet Privacy (Technology Review)

Posted Jun 8, 2012 6:51 UTC (Fri) by farnz (guest, #17727) [Link]

A browser is also allowed to send a GET without user interaction - e.g. to prefetch a link that the browser's heuristics suggest will turn out interesting. A POST cannot be sent without user interaction.

Doctorow: The Curious Case of Internet Privacy (Technology Review)

Posted Jun 8, 2012 17:05 UTC (Fri) by bjartur (subscriber, #67801) [Link]

You're thinking of the idempotent methods. GET is idempotent, along with PUT and DELETE. Once sent, they can be resent a number of times (as long as the Date header is kept intact). But furthermore, GET is safe, and can thus be sent, as already mentioned, even without the intention to permanently modify the state of the server.

In short, a GET request should at worst result in consumption of scarce bandwidth.

Then there are TRACE and OPTIONS, which should have no side-effects beyond those inherent in the transmission of HTTP messages itself.