Re: Extension HTTP methods

Anne van Kesteren wrote:
> 
> On Sun, 14 May 2006 13:59:34 +0200, Jim Ley <jim@jibbering.com> wrote:
>>> There are currently some methods that can't be allowed for security 
>>> reasons and because such method smay be introduced in the future as 
>>> well allowing arbitrary method names does not seem like a good idea.
>>
>> I think you need to list these methods that cannot be used for 
>> security reasons, to explain more of the motivations for this 
>> decision.  It also appears to be a direct reversal of the decision at 
>> the previous f2f (issue 74)  It would be good to see what had changed 
>> in between to motivate the change, as there was no public discussion, 
>> other than more support for having any verb.
> 
> I'm just stating the resolutions as they have been made here. Feedback 
> from implementors suggested that TRACE and CONNECT have issues and that 
> future HTTP methods might become problematic (new specification 
> released, servers updated, UAs are not, hole). What was raised against 

What kind of issues? Please be more specific.

Furthermore: if specifications update the definitions of methods in an 
incompatible way, that's first of all the problem of these 
specifications. The whole point in publishing specifications about new 
HTTP methods is *not* to change them in incompatible ways once they are 
deployed. If a standards body fails to adhere to that rule - their problem.

Don't cripple XHR because of that.

> that is that it hurts adoption of new HTTP methods. That's true for all 
> other types of APIs as well though. Internet Explorer 7 as opposed to 

What other types of APIs?

> Internet Explorer 6 uses a whitelist and other browsers vendors are 
> planning to do the same thing. The whitelist would contain all "safe 
> methods" currently spreaded over various RFCs.

What specifically are you referring to when you say "safe"? I guess not 
the thing defined in Section 9.1.1 of RFC2616 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>), right?

If IE7 - for instance - fails to support the ACL method (see RFC3744) - 
I would consider this a bug that hopefully will get fixed before it gets 
released.

> Mark Nottingham would report back if the IETF was ok with this approach 
> or not.

In my opinion, forbidding implementations to allow arbitrary HTTP 
methods is clearly the wrong thing to do.

(Speaking as active member of the IETF WebDAV working group, and as 
author or co-author of several WebDAV related RFCs - most of which 
defining new HTTP methods)

Best regards, Julian

Received on Monday, 15 May 2006 06:51:24 UTC