- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Wed, 10 Jan 1996 03:44:53 -0800
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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 (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Wednesday, 10 January 1996 03:51:32 UTC