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

Henrik Nordstrom wrote:
> On tis, 2007-08-07 at 10:17 +1200, Adrien de Croy wrote:
>
>> However I would strongly caution against the proliferation of methods.
>
> Ofcourse.
>
> The issue is that today there already is a lot of methods, and not easy
> to keep track of which method is defined in which RFC.
>
>> 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.
>
> Same here. But at the same time HTTP is written with method
> extensibility from start so I don't consider it an excuse..
>
that was my point regarding TCP.  Imagine if TCP had been written with 
TCP flag extensibility built in.

The success (in terms of interoperability and deployment) of TCP is due 
to several things:

1. simplicity
2. stability

any time you add complexity or change to a protocol, you reduce 
interoperability - which is arguably a protocol's prime raison d'etre.  
I'd like to see HTTP as successful as it can be.  By this reasoning 
however we'd never change anything.  I think we still need to address 
issues latent in the existing protocol, but functionality I think should 
only be added to a protocol where there is a clear benefit to a large 
majority of agents, and I don't see WebDAV in that category.

>> A layered approach might be a better solution to implementing new 
>> higher-level applications.  One that doesn't invalidate deployed 
>> servers, gateways etc.
>
> Sure, but most HTTP extensions is not really higher level. More refining
> the protocol to fit the requirements better.
>
> But extreme care needs to be taken when inventing new methods, to not
> fall into the same pitfall as for example WebDAV PROPFIND has done...
>
> Regards
> Henrik


yes WebDAV was the main culprit I was thinking of, and would have been a 
good candidate for a higher-level layer over HTTP rather than an 
extension of it.

I guess the one down-side of a method registry might be a perceived 
condoning of proliferation of methods.  Not having one arguably is a 
disincentive to it.

I wonder what the landscape will look like 20 years from now, and 
whether there should be any initiative taken to purge some of these 
things from HTTP and move them into their own layer (perhaps a separate 
layer protocol) - cleaning up HTTP on the way and setting it in better 
stead for the future.  I guess there won't be much enthusiasm for 
something like that though - it's too easy to "hack" http for specific 
purposes, and if one doesn't really care about deployment issues (i.e. 
their system works), it's not painful enough to stop people doing it.  
Proxy vendors by and large are the ones that get the hit, since there's 
always someone that wants to use one of these applications through a proxy.

Regards

Adrien



-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Monday, 6 August 2007 22:56:24 UTC