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

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 1 Mar 2002 08:32:19 -0500

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
header.

Cheers,
Geoff  

-----Original Message-----
From: Erik Seaberg [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 11:41 PM
To: [email-masked]
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?

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 1 Mar 2002 14:41:04 +0100

Thanks, Geoff.

Sorry if I keep repeating myself, but:

are the source and the output resource 

a) different resources, or

b) variants of the same resource [1].

I say "a)", and thus they need to have different URIs.

Julian

[1] RFC2616, section 1.3

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Friday, March 01, 2002 2:32 PM
> Subject: RE: Source header instead of property? (was Re: A case for
> GETSR C (or other mechanism to that effect))
> 
>

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 1 Mar 2002 15:19:11 +0100

Not speaking of the problem how the heck google is to
display search results for such source documents...

But by then we probably have extended HTML to handle
<a href="http://xyz/doc.asp" translate="F">link to interesting 
source</a>
in all browsers.

Piece of cake really.

//Stefan

---

From: Erik Seaberg <[email-masked]>
Date: 01 Mar 2002 11:33:02 -0800

Oh, I don't mean a Translate-like request header that asks for the
source resource at an overloaded URI, just that sending the source URI
in a response header could be a smaller burden than having every
output resource generator implement PROPFIND just for the sake of
answering a request for {DAV:}source for output resources that have no
other noteworthy DAV properties.  Like so:

c> HEAD /cgi-bin/foo.pl?bar=1 HTTP/1.1
c> Host: www.example.com
c> Authorization: Basic ZXJrOnBhc3N3b3Jk
c> 

s> HTTP/1.1 200 OK
s> Content-Type: text/html
s> Source: http://www.example.com/cgi-src/foo.pl
s> 	   http://www.example.com/cgi-src/MyClass.pm
s> 

c> GET /cgi-src/foo.pl HTTP/1.1
c> Host: www.example.com
c> Authorization: Basic ZXJrOnBhc3N3b3Jk
c> 

s> HTTP/1.1 200 OK
s> Content-Type: text/x-perl
s> 
s> #!/usr/bin/perl
s> ...