W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Docushare and WebDAV model

From: John Stracke <francis@netscape.com>
Date: Thu, 06 Aug 1998 15:46:54 -0700
Message-ID: <35CA325D.7BCA6F78@netscape.com>
To: ejw@ics.uci.edu
CC: "Falkenhainer, Brian C" <BFalkenhainer@crt.xerox.com>, w3c-dist-auth@w3.org, "Garnaat, Mitchell" <MGarnaat@crt.xerox.com>
Jim Whitehead wrote:

> Of course, from a user interface standpoint, exposing an internal identifier
> like a document id in the user interface is generally a bad idea,

Yeah, well, a filename is an internal identifier, too.  :-)

> Since the URL has actions embedded within it, it is unclear to me how it
> should react to non-GET requests.  For example, what should the action be if
> I perform a DELETE on
> http://demo.opentext.com/livelink/livelink?func=doc.browse&nodeid=22278
> There are competing commands here -- the DELETE says to remove the resource
> <http://demo.opentext.com/livelink/livelink> while the stuff to the right of
> the question mark indicates that a "doc.browse" operation is to be
> performed.  Weird, eh?  This is why I (and many others) think this approach
> is a poor design from an HTTP theory perspective, although we can certainly
> appreciate how it easily maps into a CGI script implementation.

Actually, even with CGI, you can have URLs that look like heirarchies.  Given
the above script, if you do a DELETE on
http://demo.opentext.com/livelink/livelink/nodes/22278, then the script will be
invoked with PATH_INFO set to "/nodes/22278" and REQUEST_METHOD set to
"DELETE".  Some HTTP servers block methods they don't know about, but others
(e.g., Apache) just pass them right through.

|John (Francis) Stracke    | My opinions are my own. |S/MIME supported |
|Software Retrophrenologist|===========================================|
|Netscape Comm. Corp.      |If God had meant us to be in the Army, we  |
|francis@netscape.com      | would've been born with green, baggy skin.|
New area code for work number: 650
Received on Thursday, 6 August 1998 18:46:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC