RE: AdvCol section 4.15

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