- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Mon, 12 Jun 2006 13:47:51 -0700
- To: "Hallvord R. M. Steen" <hallvord@opera.com>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Mark Baker" <distobj@acm.org>, "Anne van Kesteren" <annevk@opera.com>, "Pete Kirkham" <mach.elf@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>
On 2006/06/12, at 2:42 AM, Hallvord R. M. Steen wrote: > The problem is that there's no way we can guarantee correct > behavior for new HTTP verbs whose semantics are not yet defined. > For instance, should a given method be idempotent? Are its results > eligible to be cached? Etc. Regarding idempotence: the only implication of idempotence on clients relates to pipelining <http://www.w3.org/Protocols/rfc2616/rfc2616- sec8.html#sec8.1.2.2>; so, the obvious thing to do is to treat all unrecognised methods as non-idempotent. If the browser doesn't pipeline, there's nothing to worry about. Regarding caching: HTTP requires <http://www.w3.org/Protocols/rfc2616/ rfc2616-sec13.html#sec13.10> that all unrecognised methods invalidate caches that they pass through. In my testing <http://www.mnot.net/blog/2006/05/11/browser_caching>, the only browser that conforms to this requirement is Safari. What exactly is the security implication here? These sound like implementation concerns that are easily addressed by a careful reading of the spec (with a very small amount of reading between the lines, in the case of idempotence). -- Mark Nottingham mnot@yahoo-inc.com
Received on Monday, 12 June 2006 20:50:13 UTC