- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Wed, 10 Jan 1996 00:46:22 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
With regard to the wording: > # The URI in a POST request identifies the resource that will handle > # the enclosed entity as data to be processed, e.g., values from a > # form that has been filled out. Bob Jernigan wrote: > This view seems to represent a Mosaic (incl derivatives)-centric > view of clients on the Web. In our Intranet environment, the main > client is MS-Excel with appropriate add-ins for http. Isn't MS-Excel a kind of form? 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. URL schemes and their methods: http: GET, PUT, POST ftp: GET, PUT mailto: GET, POST telnet: GET(?) wais: GET news: GET (POST?) nttp: GET 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.
Received on Wednesday, 10 January 1996 00:51:08 UTC