Re: New issue: Need for an HTTP request method registry

Adrien de Croy wrote:
> 
> in principle I agree.
> 
> However I would strongly caution against the proliferation of methods.
> 
> <horse:dead:flog>
> 
> since I write a proxy, I'm biased towards proxies, but every time a 
> method is added to HTTP, we eventually get requests to support it.

Well, you probably only get them if you don't support it out of the box? 
Why don't you? The method transmission semantics are defined in RFC2616, 
and apply to all methods (minus CONNECT, perhaps).

> Even if it is painful, we can at least do that since we're software-based.
> 
> But there are zillions of deployed hardware-based HTTP gateways that 
> don't get firmware updates.  These will be broken for any new methods 
> until they are replaced.  Many of these intercept connections as well :)

If they don't support extension methods, they are already broken right now.

> A layered approach might be a better solution to implementing new 
> higher-level applications.  One that doesn't invalidate deployed 
> servers, gateways etc.
> 
> e.g. use HTTP for the transport only, not the higher-level application 
> layer.  It would solve a lot of compatibility issues for proxy and 

...but HTTP is an application protocol. The transport is TCP...

> gateway vendors, reduce obsolescence and generally improve customer 
> return on investment.  Furthermore it would restrict the scope of 
> changes required for any functionality to only those parties involved 
> (i.e. specific servers and clients) rather than all intervening HTTP 
> infrastructure as well.
> 
> </horse:dead:flog>
 > ...

Some more thoughts:

- RFC2616 already tells you what to do with unknown methods,

- unknown methods by definition aren't less safe as POST, as POST can 
already mean "anything",

- blocking unknown methods only results in applications using POST 
instead, which makes life harder for intermediates, not simpler,

- a method registry should require to state safeness (can I follow a 
redirect automatically?) and idempotence (can I retry?).

Finally, we spent an enormous time discussing this on the webapi mailing 
list, when defining XmlHttpRequest (XHR). Turns out that IE7 and Opera 
are broken, in that they block unknown methods. On the other hand, 
Firefox and MSXML's ActiveX control work as they should.

Best regards, Julian

Received on Tuesday, 7 August 2007 10:29:36 UTC