Re: Extension HTTP methods

On Thu, 08 Jun 2006 09:41:39 +1000, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 7 Jun 2006, Mark Nottingham wrote:
>>
>> Blindly standardising what one vendor does doesn't make sense; do you
>> know *why* they consider it a security feature?
>>
>> The reputed security problems with various HTTP methods have been
>> brought up many times, but I have yet to see an explanation of how they
>> actually cause a security issue greater than supporting POST does.
>
> Beyond curiosity, does it matter why? There's no point us publishing a
> spec that contradicts Microsoft's implementation if Microsoft's
> implementation is not going to change (which it isn't, if the reason for
> it being the way it is is Security).

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.

We can provide a list of verbs that MUST be supported, and say that  
implementations should allow other verbs, (that's something that should be  
in extensibility anywa, and we will probably get comments from Karl Dubost  
or W3C QA), but note for authors that implementations may not do this, for  
example due to security concerns.

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™...

Besides, I am with Mark on the principle that standardising things based  
on security is generally something this group should not do. There are  
many different security models and approaches on the web, and in order to  
make documents that are usable in implmentations it is helpful to allow  
for this, where possible.

Since security will virtually always trump standards conformance for  
implementors (there are use cases for providing insecure systems too),  
when we choose how to standardise current practice we should be wary of  
following restrictions imposed for security over openness desired for some  
use cases.

Trading off too much functionality for totally compatible interoperability  
eventually comes at the cost of assuming no new development or innovation,  
which would be a bad thing (and symbolic of a struggle against reality -  
developers *will* innovate). That said, this is something that generally  
comes to a case-by-case analysis of the particular problem...

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 02:21:00 UTC