Re: GET on a reference

I agree that this is the direction the discussion in Redmond seemed to be
pointing.

There are several things that worry me about the proposal.

There is a requirement (3.1.4) that operations on a referential member not
affect the resource it references.  The rationale for this requirement is
that there needs to be some way to operate on the referential member
itself.  If requests were automatically redirected to its target resource,
this would not be possible.

So for GET and HEAD, the client might really be wanting to see the headers
of the reference (not its target).  It looks to me as if this is not
possible if we require a 302 response.

Similarly for PUT, the client might be wanting to replace the content of
the target resource, but on the other hand it might be wanting to replace
the reference with an ordinary resource that has content.  I'm a little
fuzzy on what happens for PUTs.  Is there a way for the client to say, this
is really the location that I want to overwrite, not the redirect?

As far as indicating the type of resource, I would be more inclined to
define a new Resource-Type header that contains the value of the
DAV:resourcetype property than to reuse a different header for a purpose
other than its intended one.

--Judy

At 10:55 AM 6/25/98 PDT, you wrote:
>In Redmond, I brought up the issue of what happens when a
>non-DAV-aware browser tries to view content containing
>referential members; we were unable to agree on an answer in
>realtime, so I took on an action item to propose a feasible
>mechanism.
>
>My proposal is that GET, HEAD, PUT, or POST on a reference
>should return 302 (Moved Temporarily), with the Location:
>header indicating the target URI of the reference.  It would
>also include some DAV-specific header, indicating that the
>resource is a reference, so that a DAV-aware client would
>understand that the redirection was being done through DAV
>(as opposed to some server-specific configuration).  The
>most obvious way would be to provide a Ref-Target: header
>with the same target URI as Location:, but such duplication
>would introduce complications (what happens if the two URIs
>disagree?), as well as wasting a smidgen of bandwidth.  A
>better way would be to use a header which is present if, and
>only if, the resource is a reference--e.g., Ref-Integrity:.
>(We could also just have the DAV client check the resource's
>DAV:resourcetype property, but that would take an extra
>round trip.)
>
>So, for example, if http://www.example.com/foo/bar.ref is a
>weak reference to http://www.example.com/baz.html, we might
>have an HTTP exchange like this:
>
>GET /foo/bar.ref HTTP/1.1
>Host: www.example.com
>
>HTTP/1.1 302 Moved Temporarily
>Location: http://www.example.com/baz.html
>Ref-Integrity: F
>
>One complication is that clients are not supposed to
>automatically follow the Location: field without telling the
>user, unless the method is GET or HEAD.  This means that
>PUTting or POSTing against a referential member won't be
>totally transparent; but it'll still be possible.
>
>More generally, I further propose that we add a requirement
>to draft-ietf-webdav-collection-reqts-01.txt, specifying
>that, whenever possible, a collection created via DAV should
>be readable to a non-DAV-aware HTTP/1.x browser.  Without
>this, testing and deployment of a corpus developed with DAV
>will become a hairy problem; all the documents would have to
>be staged from the DAV server to a test server.
>
>--
>/====================================================================\
>|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
>|Software Retrophrenologist|=========================================|
>|Netscape Comm. Corp.      | Cogito ergo Spud.  (I think, therefore  |
>|francis@netscape.com      |  I yam.)                                |
>\====================================================================/
>New area code for work number: 650
>
>
>
>
>
Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm

Received on Monday, 29 June 1998 11:18:40 UTC