Re: Extension HTTP methods

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*. It's not a safe 
method, and basically *anything* can be done with it (-> SOAP). 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).

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

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.

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

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

(agreeing with the remainder)

Best regards,

Julian

Received on Thursday, 8 June 2006 07:19:02 UTC