Re: Extension HTTP methods

Bjoern Hoehrmann schrieb:
> * Julian Reschke wrote:
>> [...]
> 
> Could you propose specific text to be included in the specification with
> respect to support for HTTP methods? It is not clear to me why we are
> still discussing this, so having clear proposals for text would help a
> lot.

Fair enough.

I'm looking at the May 17 version which says (in 
<http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?rev=1.25#dfn-open>):

--quote--
method  of type DOMString
     A valid HTTP method name. The GET, POST, PUT, DELETE and HEAD 
values MUST be supported [RFC2616].
--quote--

Questions that come to mind here are:

- Is there really consensus that PUT and DELETE MUST be supported? I 
think I just heard 
(<http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0025.html>) 
that DELETE can be "dangerous". I think the disagreement comes from a 
lack of proper terminology... Any method that has non-safe semantics can 
be "dangerous" in that it can change the state of HTTP resources, 
including removing them. In that regard, PUT and DELETE fall into the 
same category as POST, while - for instance - REPORT and SEARCH fall 
into the same category as GET (!).

- When the spec says "supported", what does that actually mean? Is 
throwing an exception because of the method name allowed?

That being said, I would propose something like this:

"A valid HTTP method name (see RFC2616, Section 5.1.1). The method names 
GET, POST, PUT, DELETE and HEAD MUST be supported (i.e., accepted as 
parameter value and transmitted as specified to the server). Extension 
method names SHOULD be supported."

..and then a non-normative statement such as:

"Note to content developers: servers may reject specific method names 
for security reasons.

Note to XHR implementors: HTTP extension methods (methods not defined 
RFC2616) in general do not pose a higher danger than the HTTP POST 
method itself."

Best regards, Julian

Received on Thursday, 8 June 2006 13:47:37 UTC