- From: Graham Klyne <GK@acm.org>
- Date: Fri, 27 Jun 1997 20:29:30 +0100
- To: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Cc: http-wg@cuckoo.hpl.hp.com
At 04:04 PM 6/26/97 EDT, Ross Patterson wrote:
>
[...]
>
>While I agree with Roy Fielding that RFC 2169 should define one or more
>new HTTP methods instead of specifying semantics for certain URL paths,
>it looks to me like we're going to see more of the same, not less. The
>path to implementing a service within HTTP by specifying an object to
>retrieve is significantly shorter than specifying a new method to
>execute. This will remain true even if PEP is ever deployed widely.
I may be 'shooting from the hip' here -- I'm not conversant with all the
issues -- but is it not possible that triggering a service based upon the
type of object accessed (rather than the path to that object) might also be
a 'significantly shorter' path to implementation?
Referring to the CGI example from your earlier posting:
"/cgi-bin/..."
isn't it whatever lies at the end of the "..." bit (i.e. something the
server recognizes as a CGI script) which triggers the server into CGI
invocation, rather than the "/cgi-bin" prefix?
It seems to me that, as long as the documented behaviour for "GET" is
followed, it doesn't really matter if what is returned is a static resource
or a dynamically constructed value (apart from cache control issues).
Personally, I would say that reserving path names *in the protocol
definition* to mean requests for specific actions would be wrong. (This
doesn't mean that individual implementations cannot or should not do this,
but that the protocol specification should not preclude me from having my
home page at "/www.xxx.yyy/cgi-bin/homepage.html".)
GK.
---
------------
Graham Klyne
GK@ACM.ORG
Received on Friday, 27 June 1997 12:34:33 UTC