- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: 1999年2月16日 16:50:41 -0500
- To: "'John Stracke'" <francis@appoint.net>, WebDAV WG <w3c-dist-auth@w3.org>
- Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76DCF@x-wb-0128-nt8.wrc.xerox.com>
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. --Judy > -----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 UTC