W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect))

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 1 Mar 2002 08:32:19 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01>
To: w3c-dist-auth@w3c.org
The special header would effectively break the ability for Web Search
engines (e.g. google.com) to index the resource space, unless they were
upgraded to re-crawl the URL space with the "Translate" header, and
then store in their cache that the "Translate" header needs to be
included in the request.  Analogously, it becomes impossible to just
embed a URL in a mail message that refers someone to the source ...
you'd have to somehow include an annotation that says "and use the
Translate header when you request this URL".  These kinds of reasons
make me strongly object to either the GETSRC method or a Translate


-----Original Message-----
From: Erik Seaberg [mailto:erk@flyingcroc.com]
Sent: Thursday, February 28, 2002 11:41 PM
To: w3c-dist-auth@w3c.org
Subject: Source header instead of property? (was Re: A case for GETSRC
(or other mechanism to that effect))

The only reason for GETSRC or "Translate: F" is to overload one URI for
both the source and output resources, but it seems to me that breaks a
lot of features.  We suddenly need to duplicate most properties
({DAV:}getsrcetag, {DAV:}getsrccontenttype...) to deal well with caching
and editing.  You're likely to go through content negotiation and wind
up editing just one variant without even realizing it (or worse, store
one variant at the vanilla URI's corresponding filename and inhibit
negotiation!).  And Web development being the way it is, it's almost
certain that when GETSRC seems to usually work on simplistic servers,
hardly any clients will know how to use {DAV:}source in the cases where
it won't.

But if the output resource does have a separate URI, a PUT or LOCK or
PROPPATCH on it probably doesn't make sense, so it's not likely that
many modules will bother being compliant enough to answer a PROPFIND
request for {DAV:}source (in my case, GET clients and DAV clients are
talking to different servers entirely).  An HTTP header containing the
source URIs for an output resource (only for authenticated requests?)
should be much easier to implement; would that be more likely to be
widely adopted and used?
Received on Friday, 1 March 2002 08:32:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC