W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: intent of POST

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
Message-Id: <9601100344.aa04136@paris.ics.uci.edu>
> 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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:43 EDT