W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

Re: Extension HTTP methods

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Mon, 12 Jun 2006 13:47:51 -0700
Message-Id: <DEE6DC1C-FE91-4B3F-B582-65D0A1245856@yahoo-inc.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>
To: "Hallvord R. M. Steen" <hallvord@opera.com>

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
Received on Monday, 12 June 2006 20:50:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC