- From: Mark Baker <distobj@acm.org>
- Date: Sun, 4 Nov 2007 15:05:22 -0400
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "HTML WG List" <public-html@w3.org>
On 11/3/07, Ian Hickson <ian@hixie.ch> wrote: > > So it seems it would be good to clarify whether following an audited > > link is safe (in HTTP terminology) or not. > > > > If it is, it should use a safe method. > > If the entire HTTP request and response transaction is safe, then it > doesn't matter what method we use, since using an explicitly "safe" method > wouldn't make the transaction any safer (in the HTTP sense). You appear to be confusing two different things, Ian. When we say that an HTTP message is "safe", we're using the word to refer to the meaning of the message. In the paragraph above, you seem to be using it to refer to the behaviour of the recipient. Those are two completely different things ("orthogonal", as Julian states). HTTP, as a protocol, is concerned almost entirely about the former meaning, and hardly at all about the latter. This is key to understanding why the use of POST is actively harmful for this feature. > > Following that line of argument you need a method which is safe and > > idempotent, which is not defined in RFC2616. > > Indeed. In the absence of such a method, though, "POST" with a semantic > that is defined to be safe in the HTTP sense seems to satisfy our needs. (assuming you both mean "non-idempotent" there) > > Of course you could define one. > > It seems out of scope for HTML to define new HTTP methods. Also, you couldn't define a safe and non-idempotent method. All safe methods are idempotent by definition. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Sunday, 4 November 2007 19:05:36 UTC