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

RE: A case for GETSRC (or other mechanism to that effect)Agreed on all
points.

People interested in defining a replacement for dav:source in a separate
draft, please email me :-)
  -----Original Message-----
  From: Peter Raymond [mailto:Peter.Raymond@merant.com]
  Sent: Thursday, February 28, 2002 10:27 AM
  To: Julian Reschke; Eric Sedlar; w3c-dist-auth@w3c.org
  Subject: RE: A case for GETSRC (or other mechanism to that effect)


  Hi,

  This also surprises me...(see this section from the Salt Lake City IETF
meeting
  minutes....



          Getting source code...

          DAV:source too complex?
          Take out of 2518, put in it's own spec if people need it.
          Translate only does 1:1
          We took a vote and 4 people were in favour of removing DAV:source,
          #nobody opposed this.
          Translate header works well because it's Microsoft and because
most servers have one-2-one mapping...eg they    edit JSP but not CGI (eg C
code)

          Larry - Why not use a proxy that translates the Translate header
into a DAV:source request??
          Geoffs objection to translate is that it needs defining for all
methods not just a few as it is today.
          Clients put the translate header on every request if it is working
on the source (eg in authoring mode).

  I seem to remember (and the above enforces this memory) that we took a
vote to remove DAV:source
  from RFC2518 and we agreed.  If we fix DAV:source or if we use the
Translate header I still think
  it needs to go into a separate specification for several reasons:

  - For RFC2518 to move through the standards track we need to show
interoperability of this feature
    and we cannot do that today, we cannot even agree on the best solution

  - As far as I know we have not seen any clients/servers use the DAV:source
property (eg it is not
    implemented).

  - I am also interested in managing more than just websites and may need a
more advanced way of
    navigating relationships (perhaps between design documents and the code
that implements them or
    between firmware and circuit board designs etc).  This can best be
addressed in another specification.

  Regards,
  --
  Peter Raymond - MERANT
  Principal Architect (PVCS)
  Tel: +44 (0)1727 813362
  Fax: +44 (0)1727 869804
  mailto:Peter.Raymond@merant.com
  WWW: http://www.merant.com




  -----Original Message-----
  From: Julian Reschke [mailto:julian.reschke@gmx.de]
  Sent: 28 February 2002 09:06
  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
  > >
  > > --
  > >
  > >
  >