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

RE: AdvCol section 4.15

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Tue, 16 Feb 1999 16:50:41 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DCF@x-wb-0128-nt8.wrc.xerox.com>
To: "'John Stracke'" <francis@appoint.net>, WebDAV WG <w3c-dist-auth@w3.org>
Good catch.  We're working on rewriting this section this week, so there
will be a new (and we hope improved) draft on Friday or soon thereafter.


> -----Original Message-----
> From: John Stracke [mailto:francis@appoint.net]
> Sent: Tuesday, February 16, 1999 1:49 PM
> To: WebDAV WG
> Subject: AdvCol section 4.15
> 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 16:47:18 GMT

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