RE: DAV-Enabled field (was RE: A case for GETSRC)

It's not clear to me that the generated output from GET on executables
actually is a different resource.  First of all, it doesn't make sense to
think of it as having properties separate from that of the script.  I doubt
if anyone actually doing the URL space mapping proposed would keep around a
set of dead properties for the generated output, but the case becomes
clearer when looking at the live properties.

If I have a directory full of .ASPs, or .JSP files, and I do a PROPFIND on
that directory, will the server actually execute all of the scripts in the
directory in order, dumping their output to a temp file, to ensure that
dav:getcontentlength is correct?  I bet nobody actually does that (it would
be "considered harmful" like PROPFIND depth infinity), and if you did it
would be stupid.  I haven't checked this, but I bet that most servers return
the length of the underlying script as the length of the generated output on
a PROPFIND depth 1.  The same difficulties apply to <get-etag> and many
other live properties.  The reason this doesn't matter in practice is that
returning the wrong etag or wrong content length for generated output is
irrelevant, since in the general case it cannot be cached, and it works
functionally just as if the resource was changed before the subsequent GET,
so it's ok if the value of <getcontentlength> is different in a PROPFIND on
its parent and the actual content length returned when you do a GET.

I think that the better model is if you think of the GET method more like
the "OPEN" action on Windows or Macintosh, which means to execute this file
if executable, or else display the contents of the document.  GET is really
like a simple case of the POST method (which was originally how it was
conceived).  To illustrate this point, let's say that a particular server
said that POST on a non-executable resource (like a static file) would dump
its contents (like a GET).  Now we can clearly see GET on a script as a
simple case of POST.

Julian's argument below gets at the heart of the problem--is each set of
possible output generated by a script a different resource?  First of all,
there are many different things that can affect the output of a resource,
and most of them are not in the URL (which is the only thing that can be
used to differentiate two resources).  While the URL arguments in the query
string are one set of arguments to the script, clearly information in the
header may also be used (even in a GET method).  For example, the
authentication headers may be used to choose whose shopping cart will be
displayed, or in POST, the form values appear in headers.  If, as Julian
suggests: GET /foo/my.jsp?arg1=val1  is a different resource than GET
/foo/my.jsp?arg1=val2, then POST /foo/my.jsp with a header Arg1: val1 should
be different than POST /foo/my.jsp with header Arg1: val2.  This obviously
makes no sense.

So, here are my arguments for why each possible output generated by a script
should not be a separate resource:

* they may not have separate URLs, since not all of the arguments that cause
different output may be in the URL string--they may be in headers, or may
depend on other server state

* it is impractical to manage dead properties for each possible output

* it is computationally difficult to return dead properties (such as
dav:getcontentlength) for each possible output

Therefore, I conclude that generated output is not a resource, and
especially not a dav-enabled resource.  I would recommend that server
implementers NOT return script output as dav enabled.

Now, on to the practical argument, which will demonstrate that dav:source is
a lot less usable than GETSRC/Translate:

let's say that I have a directory full of scripts and static files.  I want
to manage them from a authoring point of view.  If I want to implement
dav:source, I need to create some virtual URL space that corresponds to the
physical URL space where the actual script source is stored.  I can make the
virtual URL space return either the generated output, or the source, at
least from an implementation point of view.  For example:

Contents of /mydir:

   foo.jsp
   bar.html
   bar.gif

In case 1, let's say I make /scripts/src/<real-path> a virtual URL space
that returns the source of any executables (for DAV clients), so where GET
/mydir/foo.jsp will return the generated output, /scripts/src/mydir/foo.jsp
will return the source.  dav:source on /mydir/foo.jsp will point to
/scripts/src/mydir/foo.jsp.  The DAV client doesn't actually want to mess
with /mydir/foo.jsp since it is generated, has bogus live property values,
doesn't respond to things like PUT, and is generally not very helpful.  Now
I'm forced into a separate tree, which is certainly annoying from a
useability point of view, and extremely annoying when doing things like
copying with Web Folders, since when I drag & drop my app from the local
filesystem to the server, my .jsp files move to another place, and when I
copy the application back down to my local PC, the .jsps were moved (even if
I was smart enough to realize where they magically went to).  So, this is a
bad solution.

In case 2, let's say I make /script/output/<real-path> a virtual URL space
that returns the generated output for the executables.  Now the DAV client
is happy, since the server space looks like the space on the client.
Unfortunately, all of the <href> tags in any HTML output are screwed up vs.
the local copy (e.g if bar.html wanted a link to foo.jsp, or vice versa),
since neither a relative nor an absolute URL will work, and the URLs needed
are server implementation-dependent.

The reality of the world is that people want to be able to move their
content creation environment back and forth between local filesystems and
DAV servers.  Any usage of dav:source would break that abstraction, since
local filesystems aren't capable of implementing virtual URL spaces.  I
think these are the practical reasons why nobody has implemented dav:source
in the past 3 years.

So, it is clear that:

* generated output (from stuff like .jsps, .asps, cgi) does not make sense
as a DAV-enabled resource, since the only methods it is likely to respond to
intelligently is GET.
* separating the URL space of generated output and source causes usability
problems, making life awkward either for the DAV client, or for the HTML
linking

I think the argument for a GETSRC method becomes clear if you mentally
rename GET to LIMITED-VERSION-OF-POST.

Reponses to a couple of other points in more recent emails:

  Alan Babich says:

"Is the source the same entity as its output?" Julian and I agree that it is
not. RFC2616 section 9.3 says it is not.

  Response:  the issue is not whether or not the source and the output are
the same "entity", but the same DAV resource.  Entity and resource are
different things.  There are three general categories of things that can
cause the output of a generated script to vary:  URL information, e.g. the
query string; header information; or server-state (like in a database).
Clearly the URL isn't sufficient to differentiate between all the kinds of
server-generated output, so the various entities that can be generated by a
script cannot be mapped as separate resources, since they won't have
separate URLs.

  Roy Fielding says:

Any server that allows clients to vary GET responses based on the Translate
header field MUST include "Vary: Translate" in every response to the GET
method in order to remain compliant with HTTP/1.1.

  Response:  Actually, RFC2616 says: "An HTTP/1.1 server SHOULD include a
Vary header field with any cacheable response that is subject to
server-driven negotiation."  So, clearly, Microsoft is in compliance with
the HTTP specification since this is not a MUST requirement.  Clearly it is
acceptable to use header values to vary the content of generated state,
whether it be the Translate header or the Authentication header, and whether
or not the Vary header is supplied is a completely orthogonal issue.

Here's another way to look at the categorization of response entities for
executables:

1) the source
2) generated output that does not vary based on input arguments from client
3) generated output varying with input arguments from client encoded in
query string
4) generated output varying with input arguments from client encoded in
request headers
5) generated output varying with server-side state (like information in a
database)

I don't see why case #2 and case #3 (in Julian's example) should be awarded
its own status as a "real dav resource" when cases #4 and #5 are not.

I'd like to see someone propose a scheme for implementing dav:source that
solves the usability problem when mapping to the local filesystem, if they
believe in dav:source.

--Eric


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Saturday, March 02, 2002 4:22 AM
> To: CJ Holmes; w3c-dist-auth@w3.org
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> CJ,
>
> I understand your frustration.
>
> However,
>
> so far you have failed to answer the following question:
>
> Are the source and it's output (from an HTTP point of view!) the same
> resource? If they aren't, they MUST have different URIs. This is a
> fundamental property of URIs and resources that you just can't throw away
> because it *seems* to be convenient for you.
>
> If you say they are, you'll have to convince us that the source
> code (of for
> example an ASP page) and it's output are different representations of the
> same thing.
>
> For instance, let's take the example of an ASP page that creates
> the list of
> current bug reports for a certain product "test". It's output is
> identified
> by
>
> 	http://server/foo/bugs.asp?product=test
>
> It can also be used for other products, so the *different* URI
>
> 	http://server/foo/bugs.asp?product=test2
>
> represents a completely different resource which only happens to
> be produced
> by the same script. Finally the script may have a default view (giving a
> form), which is identified by:
>
> 	http://server/foo/bugs.asp
>
> All these resources are different (and thus have different URIs).
>
> Let's say that http://server/foo/bugs.asp happens to be WebDAV-compliant
> resource. When you pass the URL to somebody else, s/he will
> ultimatively do
> a GET against it. What GET does is defined in RFC2616, not in WebDAV. As
>
> 	http://server/foo/bugs.asp
>
> identifies the *output* of the script, it cannot be used to identify the
> script itself (otherwise, please show us!).
>
> What you *can* do is add a DAV:source property that contains the
> URI of the
> actual script (which will actually send the source text upon GET). Some
> examples are:
>
> 	http://server/foo/bugs.asp?action=send-the-source
>
> 	http://server/foo/?source-of=bugs.asp
>
> 	http://server/foo,source/bugs.asp
>
> 	http://server/sources/foo/bugs.asp
>
> 	http://server:81/foo/bugs.asp
>
> and so on. Note that only some of these formats require a second URL
> namespace / virtual host / port.
>
>
> Finally, please see what the HTTP spec (RFC2616) says in it's first
> paragraph about GET:
>
> "9.3 GET
>
> The GET method means retrieve whatever information (in the form of an
> entity) is identified by the Request-URI.
> If the Request-URI refers to a data-producing process, it is the produced
> data which shall be returned as the entity
> in the response and not the source text of the process, unless that text
> happens to be the output of the process."
>
>
> Julian
>
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> > Sent: Saturday, March 02, 2002 3:36 AM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: DAV-Enabled field (was RE: A case for GETSRC)
> >
> >
> > >  > Yeah, but it's OUR problem, and not yours.  If our DAV
> implementation
> > >>  is unsatisfactory to our customers then we have to change it.  But
> > >>  this would let us (and other implementors) give our customers what
> > >>  they want, which is DAV access to their source files with virtually
> > >>  no configuration necessary.
> > >
> > >No configuration is necessary with dav:source other than what
> was already
> > >done to create the dynamic resource.
> >
> > I've tried to explain the real-world "hassle for no gain for most
> > people" situation on this about five times now.  I'm not going to
> > repeat it because apparently nobody on this list thinks such issues
> > merit much weight.  But I guess what administrators have to do to
> > configure their servers or how much we confuse hapless users is
> > inconsequential in the face of the prospect of adding a mote of dust
> > to the pure model of DAV.
> >
> > >  > All we need from the protocol group is a sure way to know
> that a GET
> > >>  command originated from a DAV client.  Is that so much to ask?
> > >
> > >No, the problem is that your question starts off with an awful design
> > >decision and expects the WG to validate that through another
> unnecessary
> > >and completely lame hack.
> >
> > It starts with trying to find a way to accommodate users who don't
> > give a darn about using DAV on display resources, and would like to
> > use DAV to edit their sources without screwing with the URL.  If it
> > was just a minority of users, it wouldn't be an issue.  But it is a
> > majority of users and installations, so it is an issue.
> >
> > Translate exists because it solves this problem by identifying GETs
> > >from DAV clients.  If we have to use Translate to give our customers
> > what they want, then so be it.  I was just hoping we could get
> > something defined by a group of thoughtful people instead of
> > something undocumented.
> >
> >
> > cjh
> >
> > --
> >
>
>

Received on Monday, 4 March 2002 16:53:40 UTC