Re: Extension HTTP methods

"Anne van Kesteren" <annevk@opera.com>
> 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.

Sure, but if the groups aim is to work in public, then it needs to work in 
public, ie provide the motivations for the decisions, and not just the 
decisions, otherwise exactly what happens here happens and all we get is 
discussion on the public list that exactly reflects the existing discussions 
already had at a f2f or in a telcon etc. Which wastes everyones time.  Just 
reporting decisions is unhelpful, especially when they reverse previous 
public decisions of the group.

> What was raised against 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 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.

I assume the whitelist is a SHOULD requirement - a MUST requirement would be 
absolutely wrong as it prevents user agents from denying them for security 
reasons.

Cheers,

Jim.

Received on Sunday, 14 May 2006 12:30:44 UTC