Re: intent of POST

> However, all of this reminds me that there is an unfortunate
> intertwining of methods and URL schemes. We might not want to add new
> methods to HTTP if those methods might not be representable in other
> protocols, less we make other-protocol gateways not have an obvious
> implementation. 

No, HTTP methods are extensible without any such constraint.
Any resource/server which does not support a particular method is
capable of saying that it doesn't support that method.  In practice,
a particular method is only used when it is known to be supported,
so such concerns are unwarranted.

> URL schemes and their methods:
> http:  GET, PUT, POST
> ftp:   GET, PUT
> mailto: GET, POST
> telnet: GET(?)
> wais:  GET
> news: GET (POST?) 
> nttp: GET

news supports POST.  nntp (which, last I checked, is not implemented
anywhere other than libwww-perl) also supports POST.

> and HEAD means first-part-of-GET
> If you add other methods, you might have to at least define whether
> proxies are expected to implement any protocols for those other
> methods.

No, that decision is completely up to the proxy -- it can implement any
methods it chooses to implement.  Client libraries like libwww-perl
allow clients to use any method, including those that aren't predefined
by implementors like myself, because that is how HTTP was designed.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Wednesday, 10 January 1996 03:51:32 UTC