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: Thursday, February 28, 2002 6:59 AM
> To: w3c-dist-auth@w3c.org
> Subject: A case for GETSRC (or other mechanism to that effect)
>
> ...
>
> First, I appreciate what the DAV working group is trying to do by
> allowing multiple sources for a given document, and making each
> source a separate resource.  I won't bother denying that it is useful
> to some people and interesting in its own right.  I totally see the
> logic in it.  But it is an abstraction that is useful only to a small
> minority of users, and is very difficult to implement.  If you doubt
> that, I direct you to the total lack of implementations.  But I'll

I think the lack of implementations is caused by

- people choose to support the Translate header because they really haven't
a choice (as this is what the Microsoft clients use),

- the description of the source property is buggy and hard to understand
(this could be fixed).

> make a case on other grounds, as well.
>
> With any DAV request except GET the process is rather straightforward:
>
> 	A virtual host is selected
>
> 	Security determines what rights the user has on the URL.  In
> the Apache universe that means PUT, POST, MKCOL, GET, etc..  In our
> universe (WebSTAR) that means read, write, list, mkdir, etc..
>
> 	We figure out what file the URL maps to.
>
> 	In deciding which plug-in will handle the request, a DAV
> plug-in simply claims anything with a DAV-specific method.  If it is
> MKCOL, DELETE, etc. then the DAV plug-in claims it.
>
> 	DAV handles the request, within the limits set by the
> security plug-in.
>
> All of this works great, until we get to the GET method.  Plug-ins
> have no way of knowing the difference between a normal GET that
> should be handled normally, and a GET that is intended to retrieve
> the source of a document and requires special permissions.  In effect
> we have TWO semantics for GET.  And so we start creating fake URL
> spaces.  But we quickly run into security and configuration hassles.

I object to the term "fake URL space". Defining separate namespaces for
sources and outputs seems like a logical solution to me.

> The bottom line is that there's no way to provide good DAV access
> without some special configuration on the server.  And it isn't the
> result of some kind of design error by the implementor, but a basic
> issue with how the protocol is designed.  Unless you are only dealing
> with static content you MUST set up a whole new URL space to do DAV
> at all.

Yes. So? I don't understand why this is a problem per se.

> In practice setting this up is such a bother that what most
> administrators do is create a whole new virtual host with all
> plug-ins disabled in order to get it done.  Is it just me, or is it
> entirely ridiculous that server administrators have to double the
> number of virtual hosts they support just to give decent DAV access
> to their users?

Well, they don't. How this is done is completely implementation-specific,
I'd say.

> ...

I think we need to answer this questions.

Given an ASP file and it's output -- are these two different resources, or
are they different representations of the same resource? In the first case
they'll *need* different URIs, in the other case normal HTTP variant
handling can be used.

Even when you choose the latter -- how do you treat then output resources
with multiple source resources?

Received on Thursday, 28 February 2002 04:17:25 UTC