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 01:19:09 UTC