Re: Extension HTTP methods

Charles McCathieNevile schrieb:
> 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).

How is PUT more dangerous than POST, if a POST can overwrite an existing 
resource as well?

In particular, if "dangerous" methods aren't available through XHR, 
server implementors may be encouraged to add alternative POST interfaces 
for these "dangerous" actions (such as in SOAP), so nothing is won in 
the end...

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

But at least it's an indicator (meaning that somebody actually *has* 
done a security review :-).

>>> We can provide a list of verbs that MUST be supported, and say that 
>>> implementations should allow other verbs, but note for authors 
>>> thatimplementations 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.

Well, that's the point I violently disagree with. By disallowing 
"unknown" methods, this spec would be profiling HTTP and thus 
restricting what other standards bodies can do. As far as I am 
concerned, this is something this WG clearly shouldn't do.

> 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 

Well, of the shipping UAs Firefox and IE 6.x support all methods, while 
Safari and Opera are clearly buggy (they silently replace unknown 
methods by GET; if they reject certain methods, they should do that 
explicitly by throwing an exception, not by silently doing something else).

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

So what would be the recommended spec text then (yes, I know, I'm 
supposed to make a proposal myself...).

 > ...

Best regards, Julian

Received on Thursday, 8 June 2006 12:17:19 UTC