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

From: "Jason Crawford" <[email-masked]>
Date: Fri, 1 Mar 2002 10:57:29 -0500

I didn't understand Julian's response clearly, so I'll take another stab at
a response.

Firstly I assume the reason that you are discussing difficulty is that
you're
trying to prove that GETSRC is easier to implement/use than DAV:source.
I do agree that GETSRC is probably at least a little easier, but if we're
talking about a system where one output resource maps to one source
resource, they both are almost the same.  (If not, that needs to be
proven.)
To compare GETSRC handing a 1::1 mapping to DAV:source handing a
many:many or many::many mapping of source to output isn't a fair
comparison of GETSRC vs DAV:source.   That's more a comparison
of the complexity of supporting 1::1 vs many::1 mappings.   If it's really
DAV:source vs GETSRC that you want to compare, you only should be
looking at 1::1 mappings.

OTOH... if you're not really talking about GETSRC vs DAV:source, but
really just talking about the complexity of supporting a 1::1 mapping if
you are also supporting a many::many or many::1 mapping, then I think that
comparison is more appropriate, but I also think that we haven't clearly
defined
a protocol that supports many::many yet.  As we've pointed out, DAV:source
really isn't clearly defined.  We don't know what kind of flexibility it
will be defined
to support so we don't know what kind of burden it creates.  Until it's
defined, we
can't really envision what it's like to support a many::many mapping.  I
hope
we rapidly define how DAV:source supports composition from many underlying
resources.  Then we do the comparison.

Anyway... what I say below assumes you're talking about comparing GETSRC
vs DAV:source on a server that just supports 1::1 mappings.   If this is
not
your scenario,  please forgive me.

> >Why is it easier to get the server to implement GETSRC
> >(which requires it both to locate, and then retrieve the
> >contents of the source) than it is to get the server
> >to implement PROPFIND <DAV:source>, where it just has to
> >locate the source, and return its URL?

> Well, you can't always "just locate the source".  If the source
> really is in a different location than the "normal" URI then your DAV
> module probably has no knowledge of it.
But in your case of GETSRC you have to do the same thing.  If it's
hard for one, it's hard for the other.    Just because a server
supports DAV:source doesn't mean that it's going to put it's
data in weird hard-to-find places.  It's very likely to put
everything physically in the same place a pure GETSRC server
would.

<<
Which means now you have to
teach JSP to be DAV-aware and answer PROPFIND requests, or teach your
DAV module all about what URIs are served by which other modules and
how the two URI spaces map to each other.
Having the JSP be DAV-aware is of course a terrible burden, but I
don't think anyone is suggesting it needs to be.  The mapping would
not be done at the JSP layer.  And even if it would be, it would
be the same mapping that one would use for a pure GETSRC server.

<<
In the more common case where "GET x" is dynamically generated from
some source at the same URI, then there's hardly anything to be done
at all to support GETSRC.  All of the same machinery that normally
locates a file works just like it did before, which is the beauty of
it.
That sounds great.  But the same would almost certainly be true for
a server that supports DAV:source.  It doesn't have to be true for
such a server, but it doesn't have to be true for a pure GETSRC
server either.  But it seems reasonable to keep the underlying
resource where you've described so both implementations are likely
to do it that way.

<<
The only differences are:

             1. The security module checks to make sure that the user has
permission to "GETSRC x".  In Apache, this is just a matter of adding
GETSRC to the list of methods a user is allowed to use within a given
realm.

             2. The PHP/JSP/Whatever plug-in doesn't try to pick up the
request, because it doesn't know what to do with a GETSRC method.
(Just like it doesn't try to claim anything with PROPFIND or DELETE
methods.)  In fact, all plug-ins that work only with GET, HEAD, and
POST methods just ignore the request entirely, which is what you want
for serving "source" data.

             3. Either the DAV module can claim the request, or the
mechanism that serves static files can serve the request.  In our
case (WebSTAR) we would probably just let the "default" plug-in do
it, since that module normally serves static content without
interpretation and it supports byte ranges, which is handy.  There's
no point in duplicating that code in the DAV plug-in.
I think these three points are more to the point.  This sounds pretty
easy and that was half your point.  The other half of your point is that
it's hard to support DAV:source.  I think a supporter of DAV:source would
say that they'd just install a filter in Apache for URL's with a magical
something in them that distinguishes them and would handle all method calls
to those resources. If you want to prove that
doing DAV:source is much harder than doing GETSRC, someone still needs to
show that doing DAV:source is hard.  My intuition tells me it isn't
as easy as GETSRC, but that it probably couldn't be described as hard.

Again, this is all only for a server that is only supporting 1::1 mappings.
Any other type of server isn't clearly defined yet.

FWIW... I don't think anyone so far has proposed that a server support
GETSRC without supporting DAV:source, so pointing out that GETSRC is
easier for a server to implement than DAV:source is a moot point
because in the current proposals the servers would implement DAV:source
anyway and implementing GETSRC would be an optional extra effort (only?)
to offer clients a way to access the source of a resource in single HTTP
request rather than having to do a PROPFIND first.

Anyway, see my comments at the top of this posting.  They might make much
of this moot.

J.

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 4 Mar 2002 10:18:55 -0800

Accidentally caught by the spam filter. I have added <[email-masked]>
to the accept2 list.

- Jim

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 2:28 PM
To: [email-masked]
Subject: [Moderator Action] Re: A case for GETSRC (or other mechanism to
that effect)

On Thu, Feb 28, 2002 at 09:04:25AM -0500, Clemm, Geoff wrote:
> As I recall, I was willing to consider the Translate header
> or a GETSRC method, if I was the only one who found them
> objectionable.  I consider a separate URL space for authoring
> a superior approach, since I believe separate URL spaces
> are a simpler model, and one that will prove to be more
> extensible.  It also is very compatible with common web server
> extension mechanisms, which allow you to dispatch to different
> modules based on what part of the URL space you are operating in.
>
> So with support from Julian, it no longer is "just me", so I
> revert to my natural position, which is against both the
> Translate header or a GETSRC method.

Just in case anyone here has forgotten my vehement objections to GETSRC,
let me make it perfectly clear.  I will personally veto any attempt to
violate one of the primary principles of the Web architecture within the
Apache httpd server.  We will not implement GETSRC or anything like it.
That is just too bad of an idea to allow it to be further propagated.
I've already stated my reasons for why it doesn't belong in any protocol
related to the Web, and while I cannot control what the WG decides to put
in the standard for WebDAV, I will exercise my right not to implement it.

We will not implement the Translate header field either, except where
necessary to preserve bugward compatibility with deployed clients.
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.  Since Microsoft is too
lazy to implement Vary properly in their client libraries, the effect
would be to disable client-side caching of all DAV-authorable resources.

The source property is the only mechanism I know of that truly allows the
Web interface to be used for authoring of the source resources of
dynamically generated content.  It does not mean that the server keeps
track of the C files of a compiled handler -- that would be ridiculous.
What it means is that the server will not allow a client to directly PUT to
a
resource that is dynamically generated, and the dav:source property should
simply list the URL(s) that make up the authorable components of that
resource (whether that be negotiated variants, SSI-included components,
site-wide header/footers, or external source trees).  It is a level of
redirection that is necessary to preserve the semantics of the Web
interface.
Quite frankly, if a person cannot implement that in a trivial amount of time
then I'd like to know how their Web server manages to generate the dynamic
content in the first place.

WebDAV cannot move this feature into another specification.  Without it,
the protocol is nothing more than a crippled FTP and has no business being
a proposed standard.

Sincerely,

Roy T. Fielding, co-founder, Apache HTTP Server Project
                 ([email-masked])  <http://www.apache.org/>