W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1999

AdvCol section 4.15

From: John Stracke <francis@appoint.net>
Date: Tue, 16 Feb 1999 18:48:56 +0000
Message-ID: <36C9BD98.FE6DF8E6@appoint.net>
To: WebDAV WG <w3c-dist-auth@w3.org>
In section 4.15 of the current Advanced Collections protocol Draft, we
have:

     In a request-URI /segment1/segment2/segment3, any of the paths
     /segment1/, /segment1/segment2/ or /segment1/segment2/segment3
     may identify a reference.  (See [URI], Section 3.3, for
     definitions of "path" and "segment".)  If any segment except
     the last segment of the path identifies a reference, that
     reference MUST have as its target a collection.  Otherwise,
     the request will fail.

I'm not sure this MUST is appropriate in all cases.  Suppose /segment1
is a reference that points to a CGI script? CGI includes the PATH_INFO
header, which means that CGI scripts can be written that behave as
collections.  So, if /segment1 points to /foo.cgi, then it may be
reasonable for /segment1/segment2/segment3 to get redirected to
/foo.cgi/segment2/segment3.

I believe that a more appropriate behavior may be for the server to
expand the path and either pass back the resulting URI without prejudice
(if it's a redirect reference) or process it exactly as if the resulting
URI had come in in the first place (if it's a direct ref).  If this
results in an error, fine; but don't add extra rules that will create
errors where none may be needed.

(Yes, there are efficiency issues in having the redirect reference point
the client at an invalid URI; but, given weak refs, we already have
them.)

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




CUBElink Internet Services.
Received on Tuesday, 16 February 1999 13:47:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:49 GMT