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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Friday, March 01, 2002 1:06 AM
> To: Clemm, Geoff
> Cc: w3c-dist-auth@w3c.org
> Subject: 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

If it doesn't (which is completely OK), then DAV:source will be empty,
GETSRC will fail (?) and GET/Translate:f will something unspecified, right?

> 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.

I think you can't have both. Either do DAV-enable your output-resources, or
don't. If you do, this is a WebDAV problem, and WebDAV has a solution for it
(DAV:source). If you don't, it's outside the scope for WebDAV.

IMHO it makes perfect sense to only DAV-enable the source resources. Why
would you want to Author or Version output resources?

> 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

Is it really at the same *URI*? Or does it only happen to be stored in this
place in the local storage of the fileserver?

If it is, it would be the same resource (as per definition of URI). Is it? I
think this is a key question.

> 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.

Received on Friday, 1 March 2002 04:26:07 UTC