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

On tis, 2007-08-07 at 11:59 +1200, Adrien de Croy wrote:

> Anyway, I guess not that useful a simile.  The point I was trying to 
> make is we shouldn't be adding new methods and status codes unless 
> there's absolutely no other way to do something, and that thing really 
> needs to be done.  There's pretty much always another way.

I don't share this view entirely. There is several valid reasons for
extending HTTP. HTTP is not a transport, it is an application protocol
with a specific focus.

Things like WebDAV certainly merits it's existence within HTTP. It's
just unfortunate that PROPFIND (and it's relatives) didn't get the
protocol attention it required before it got specified and relatively
widely deployed. But I don't consider it too late to fix, even if it
will take time.

Before extending HTTP one must carefully consider

a) Isn't there anything already in HTTP which can express what I am
after. I.e. could it be solved by defining a standard URI namespace
schema and content types, using existing methods?

b) If not, is HTTP really the proper protocol for the task?

Selecting HTTP only because it runs over port 80 and is often accepted
by firewalls is not a valid reason to use HTTP or to extend HTTP, even
if this is probably the most common reason why more and more non-web
applications layer themselves over HTTP..

Regards
Henrik