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

Accidentally caught by the spam filter. I have added <fielding@apache.org>
to the accept2 list.

- Jim

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org]
Sent: Thursday, February 28, 2002 2:28 PM
To: w3c-dist-auth@w3c.org
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
                 (fielding@apache.org)  <http://www.apache.org/>

Received on Monday, 4 March 2002 13:18:40 UTC