RE: A case for GETSRC (or other mechanism to that effect)

>Why is it easier to get the server to implement GETSRC
>(which requires it both to locate, and then retrieve the
>contents of the source) than it is to get the server
>to implement PROPFIND <DAV:source>, where it just has to
>locate the source, and return its URL?

Well, you can't always "just locate the source".  If the source 
really is in a different location than the "normal" URI then your DAV 
module probably has no knowledge of it.  Which means now you have to 
teach JSP to be DAV-aware and answer PROPFIND requests, or teach your 
DAV module all about what URIs are served by which other modules and 
how the two URI spaces map to each other.

In the more common case where "GET x" is dynamically generated from 
some source at the same URI, then there's hardly anything to be done 
at all to support GETSRC.  All of the same machinery that normally 
locates a file works just like it did before, which is the beauty of 
it.  The only differences are:

	1. The security module checks to make sure that the user has 
permission to "GETSRC x".  In Apache, this is just a matter of adding 
GETSRC to the list of methods a user is allowed to use within a given 
realm.

	2. The PHP/JSP/Whatever plug-in doesn't try to pick up the 
request, because it doesn't know what to do with a GETSRC method. 
(Just like it doesn't try to claim anything with PROPFIND or DELETE 
methods.)  In fact, all plug-ins that work only with GET, HEAD, and 
POST methods just ignore the request entirely, which is what you want 
for serving "source" data.

	3. Either the DAV module can claim the request, or the 
mechanism that serves static files can serve the request.  In our 
case (WebSTAR) we would probably just let the "default" plug-in do 
it, since that module normally serves static content without 
interpretation and it supports byte ranges, which is handy.  There's 
no point in duplicating that code in the DAV plug-in.

>-----Original Message-----
>From: CJ Holmes [mailto:cholmes@4d.com]
>Sent: Thursday, February 28, 2002 6:17 PM
>To: Clemm, Geoff
>Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
>>I agree with Julian's question, i.e. why don't you just use
>>some natural URL to expose your editable source.  In general, the
>>file extension of the actual file containing your editable source
>>will not be ".html".  It will be .asp, .jsp, or whatever.  So the
>>natural URL for the jsp source for /x/y/foo.html is /x/y/foo.jsp.
>>Why not just use that URI to identify your source resource?
>
>Most people don't configure their servers that way.  If you want the
>output of /x/y/foo.php then you "GET /x/y/foo.php".  Short of a
>different method or something like the "Translate" field there's no
>natural way to tell the difference (both semantic and security)
>between a "get the source" and "get the output".
>
>And even in cases where where servers are configured this way, you
>have problems in trying to implement DAV:source or anything like it
>properly.
>
>What happens when "FINDPROP /x/y/foo.html" is requested?  If the DAV
>module is responsible for handling it, then it has to understand
>enough about the server's and other plug-ins' configuration to figure
>out who creates that URI and what the appropriate source is.  Which
>means your DAV plug-in has to be rather tightly integrated with all
>of your other plug-ins.
>
>On the other hand you could just let PHP handle PROPFIND for the URIs
>it generates.  But for that implementation model to be consistent you
>need to DAV-enable every dynamic content creation tool and every CGI.
>I don't think everyone is up to that.
>
>Again, DAV:source makes perfect sense for tightly integrated content
>management systems, but not for the common case of web servers that
>want to add DAV access to their source content.
>
>cjh
>
>--


--

Received on Thursday, 28 February 2002 19:09:03 UTC