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

I think the point is that for every method other than GET, the method
operates on a particular source object, not a set of them.  dav:source is
actually trying to track one level beyond that.  Translate: F, or GETSRC, is
just trying to get back the same contents that were PUT to that location.

The only time Translate/GETSRC is relevant is for executables (cgi's,
servlets, etc.) at a particular URL which generate some dynamic content.
So, there are really three different sets of content we are looking at:

  1)  the generated output returned by GET

  2)  the executable that generates the content for GET, and which is the
object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, MOVE, COPY,
...)

  3)  the multiple source files that were used to generate the executable


The GET method returns resource #1, dav:source (if it were actually
implemented by anyone) would list #3.  Translate: F, or GETSRC, returns
resource #2, which is the one logically consistent with the other WebDAV
methods.

Actually figuring out #3 is something the equivalent of makefile dependency
tracking, and is not generally available even in a development environment,
which is something that WebDAV is certainly not.

Real-world experience has shown that:

* nobody actually tracks multiple source files for an executable
* people sometimes want to actually get the executable contents

Nobody has actually come up with a real-world use-case for dav:source, but
whether or not dav:source is deprecated or not, it's actually identifying a
different set of content than Translate: F / GETSRC.

And, once you realize that you need Translate: F or GETSRC, you might as
well use Translate: F, as you will have no problem getting interoperable
implementations, and it is functionally equivalent to GETSRC.

--Eric


> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, February 28, 2002 1:06 AM
> To: Eric Sedlar; w3c-dist-auth@w3c.org
> Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
> Eric,
>
> that comes as a suprise.
>
> As far as I remember the discussion we concluced that:
>
> a) the Translate header (or GETSRC) solves only a very specific
> part of the
> problem (when there's a one-to-one mapping between source and output),
>
> b) the source property needs additional work to become usable, but it's a
> more generic solution.
>
> So as far as I am concerned, the plan was to fix the source
> property (maybe
> be taking it out of RFC2518bis and to fix it in a sperate draft).
>
> If there were out-of-band discussions, I'd certainly like to hear
> about it.
>
> Julian
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Thursday, February 28, 2002 7:19 AM
> > To: w3c-dist-auth@w3c.org
> > Subject: RE: A case for GETSRC (or other mechanism to that effect)
> >
> >
> > Actually, I think Lisa & I convinced Geoff (the big holdout against the
> > Translate header) to give in at the last IETF meeting.  Are there
> > any other
> > holdouts with good reason to have a problem with the translate header?
> >
> > --Eric
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> > > Sent: Wednesday, February 27, 2002 9:59 PM
> > > To: w3c-dist-auth@w3c.org
> > > Subject: A case for GETSRC (or other mechanism to that effect)
> > >
> > >
> > > I've been reading the archives, and following the long-running and
> > > sometimes contentious conversation over retrieval of source
> > > documents.  Maybe bringing this up will get me kicked off the list,
> > > but we'll see.
> > >
> > > 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
> > > 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.
> > >
> > > 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.
> > >
> > > 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?
> > >
> > > And all of this is so complicated for something that *should* be
> > > really simple!  From most servers' point of view DAV is a way to let
> > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic
> > > files and edit them and save them back onto the server.  All of this
> > > business about an arbitrary number of sources of arbitrary types as
> > > properties of a single resource don't do our users one bit of good,
> > > but the implementation is quite burdensome.
> > >
> > > What we really need from the DAV protocol is a way to know that a
> > > given request is intended to retrieve the source of a document,
> > > without having to also posses knowledge about the DAV configuration,
> > > or which URL spaces have been quarantined for use exclusively for
> > > WebDAV, and without having to create special areas in the URL space
> > > that don't actually map to anything else in the universe just so we
> > > can turn off all the plug-ins for a few requests.  Thus the
> > > suggestion for a GETSRC property.
> > >
> > > I've read the arguments that ask about FINDPROP and other methods
> > > that act on a resource, and having to double the number of methods to
> > > support FINDPROP and FINDPROPSRC, etc..  But in most server
> > > implementations when you get the properties of a .php or .ssi file
> > > right now, what are you getting?  In practice you're getting the
> > > author and lastmod date and other information about the SOURCE, not
> > > the output.  I don't know of anybody who is executing a .php file and
> > > then returning the properties of the output -- it (a) isn't practical
> > > because of all the side-effects it would cause like CPU load and
> > > errors and code running that you didn't really intend to run and (b)
> > > isn't useful because nobody cares one whit about the DAV properties
> > > of PHP output.
> > >
> > > I suggest that we just stop considering GET to be a DAV method at
> > > all.  GET has nothing to do with DAV any more than POST does.
> > > Instead of GET, we should be using GETSRC (or whatever you want to
> > > call it), always.  If you want the output of a source which has been
> > > run through PHP or SSI or whatever, then fire up your web browser and
> > > use a GET or POST method.  Otherwise, use your DAV client and GETSRC
> > > (or whatever).
> > >
> > > When you work with the properties of a resource, you are working with
> > > the properties of the resource you receive from a GETSRC command.
> > > When you GETSRC, you receive the same data that you PUT.  When you
> > > GET or POST, you receive what the server generates from the source
> > > and your input.  In some cases that happens to be the same as the
> > > source (static files).
> > >
> > >
> > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV
> > > client may use GET instead.
> > >
> > > Does not preclude a document from having multiple sources at
> > > different URIs, for the 5% of implementations that need such
> > > functionality.
> > >
> > > Advantages of this approach:
> > >
> > > 	Works well with existing security modules for Apache and
> > > other servers.  Just add GETSRC to the list of methods a user is
> > > allowed to use.
> > >
> > > 	Provides one semantic for GET (the existing semantic from
> > > HTTP/1.1 spec) and only one semantic.
> > >
> > > 	Is far more likely to be implemented, and implemented WIDELY,
> > > than the src property ever will be.
> > >
> > >
> > > This is a major, major problem with the protocol.  This is in not an
> > > indictment of anybody's abilities.  Even as a prospective implementor
> > > reading the spec carefully I didn't appreciate the magnitude of the
> > > problem until I set out to really implement it, and then it became
> > > nearly intractable.  Even the reference implementation doesn't
> > > implement it.
> > >
> > > The DAV group can take this issue in hand and come up with a solution
> > > people are willing to implement, or the ad-hoc solutions will become
> > > de-facto standards.  (ie: Translate).  Personally, I would rather see
> > > this solved by the DAV working group.
> > >
> > >
> > > cjh
> > >
> > > --
> > >
> > >
> >
>
>

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