Re: Extension HTTP methods

On Thu, 08 Jun 2006 17:18:44 +1000, Julian Reschke <julian.reschke@gmx.de>  
wrote:

>
> Charles McCathieNevile wrote:
>> It's true that it makes no sense to standardise something that isn't  
>> going to get implemented. Opera are also concerned that there may be  
>> security implications in allowing any random verb.
>
> Please be more specific. POST today allows *anything*.

Well, POST allows you to send anything. DELETE and PUT actually have  
semantics that make them much more dangerous (and much more useful, if  
you're building very simple publishing systems).

> ... On the other hand, other extension methods defined in standards  
> track RFC do have strictly defined semantics, and usually none of these  
> are a security risk (otherwise they wouldn't have passed IESG review).

Hmm. IESG review doesn't prove something isn't a security risk - but nor  
does the WebAPI or some implementor's say-so prove that it is.

>> We can provide a list of verbs that MUST be supported, and say that  
>> implementations should allow other verbs, but note for authors that 
>> implementations may not, for example due to security concerns.
>
> Why can't the spec just be silent about it? If there's a "SHOULD" to  
> support other methods, then I think a white-list approach wouldn't be  
> compliant.

The point about the white-listed MUST verbs is that it provides a base set  
that are a strong indicator of reliability (as far as we know everyone  
does these, and if you make a new implementation you "must"), with a  
statement that while we accept people may have a reason for ignoring the  
recommendation to allow other verbs, we think in general that it is a good  
idea.

Since both authors are expected to read the spec to know how to construct  
an XHR, and implementors should read it to know how to build a new XHR  
implementation and what it should be doing, we need to put a bit extra  
each way...

>> This allows for implementations that restrict the set of available  
>> verbs, and also allows development that remains conformant with the  
>> specification. From time to time there are new verbs that people like,  
>> and even if not every implementation offers them, their development is  
>> a Good Thing™...
>
> The problem here is that by having to update user agents to support  
> them, this working group restricts the ability of other standards bodies  
> to use new HTTP methods as extension point.

There is no requirement to update user agents to support them. The point  
is that some user agents will, others just won't, and specifying that they  
do just makes the spec more fictional and thus less useful (this was Ian's  
major point, I think). Other standards bodies wanting to extend HTTP is  
probably a good reason to allow extended methods, so we don't have to  
change the spec or go tell foo.org that their new work is incompatible  
with our spec until we make another revision.

> We've already seen people going to the CalDAV mailing list (after  
> last-call...) asking to drop the use of the REPORT method because of  
> WEBAPI.

cheers

Chaals

-- 
Charles McCathieNevile                     chaals@opera.com
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/

Received on Thursday, 8 June 2006 12:12:40 UTC