Subject: Re: Redirect References Spec: "Passthrough" Header

From: [email-masked]
Date: Wed, 25 Aug 1999 13:15:17 -0400

I think the Passthrough header is fine. Referencing aware clients can use the
passthrough header without having to access the properties of a resource first.
However, I don't understand why Passthrough: T wouldn't apply to the target
resource and not return a 302. Seems like the client knows what it wants to do
and is aware the request-URI is a reference. Why require the extra round trip in
this case? Second, I don't think we should special case method behavior based on
resource type. That is, Passthrough isn't specified, return 302, if it is
specified, do what it says for all methods. We shouldn't make cases like if this
is an XXX method whose request URI is reference to a collection do one thing,
otherwise do something else. This makes the protocol too complicated and
brittle. It will inhibit server creation and interoperability, and will result
in client behavior that will be difficult for users to understand and predict.
The protocol should provide basic core capabilities that clients can exploit for
various purposes in an interoperable way. For example, MOVE vs. collection
merge, exposing vs. hiding redirect references, shallow or deep locking, etc.

"Slein, Judith A" <[email-masked]> on 08/25/99 11:19:20 AM

To:   "'WebDAV'" <[email-masked]>
cc:

Subject:  Redirect References Spec: "Passthrough" Header

Yaron argues that we should get rid of the Passthrough header, and instead
have a property analogous to the DAV:source property.  This issue was
discussed by the design team last January (see minutes of 1/14/99), but it
will be good to get their discussions into the mailing list archives now:

Some Background

What is the Passthrough header? For redirect references, the default
behavior (in the absence of a Passthrough header) is to respond with a 302
and the location of the target resource.  Then the client can resubmit the
request to the target resource.  In a few cases, the default behavior is to
apply the method to the redirect reference.  The Passthrough header allows a
reference-aware client to control whether the response will be a 302 or the
method will be applied to the reference.  Passthrough: T means respond with
a 302, Passthrough: F means apply the method to the reference.

(The name "Passthrough" made more sense in the days when we had direct
references.  In the case of direct references, Passthrough: T meant apply
the method to the target resource, while Passthrough: F meant apply it to
the reference.)

Arguments for Using a Property:

1. Using a header to determine what resource the method will be applied to
is a bad thing.  A server should be able to tell just from looking at the
Request-URI what resource to apply the method to.  The server would have to
examine the Passthrough header to determine what access control to apply,
and whether caching is appropriate.

(Note: For redirect references, Passthrough doesn't actually change the
resource the method gets applied to, but it would if used with direct
references someday.)

2. The Passthrough header is just like URL-munging, and that's bad.  It's
bad for 2 reasons:  When it is used to
append an operation to a URL (<URL>;op=checkout), it is unclear what order
to perform operations if request method is anything other than GET. In
addition, there is the possibility of collisions in the url-munging space.

(Rebuttal: Neither of these considerations applies in the case of
Passthrough.  No-passthrough has consistent semantics no matter what method
it gets applied to, and there's no problem like the order-of-operations
problem.
And there is no possibility of collections here because we are defining
Passthrough as part of a spec.)

3.  Keep a consistent style through all the WebDAV specs.  We used
DAV:source, so let's use the same approach here.

(Rebuttal: The cases aren't actually analogous.  In the case of DAV:source
there really were 2 separate resources we needed to be able to address.  The
test for this is whether you might want different access control on the 2
resources.  But here if you ask, might we want different access control on
the reference-as-mediator vs. on the reference-as-itself, the answer is
"No".  So we have only one resource.)

Arguments against Using a Property

1. Two URLs would mean that 2 entries in the namespace would be used up for
every reference created.

So at the time, the decision was made to stick with the Passthrough header.

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: "Slein, Judith A" <[email-masked]>
Date: Thu, 26 Aug 1999 10:05:45 -0400

Good point.

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169

> -----Original Message-----
> From: John Stracke [mailto:[email-masked]]
> Sent: Wednesday, August 25, 1999 12:15 PM
> To: 'WebDAV'
> Subject: Re: Redirect References Spec: "Passthrough" Header
> 
> 
> "Slein, Judith A" wrote:
> 
> 2.  Without Passthrough:, how do you find the property? 
> PROPFIND would get
> 302d; you'd have no way to apply it to the reference itself.
> 
> --
> /=============================================================\
> |John Stracke    | My opinions are my own | S/MIME & HTML OK  |
> [email-masked]|============================================|
> |Chief Scientist | NT's lack of reliability is only surpassed |
> |eCal Corp.      |  by its lack of scalability. -- John Kirch |
> \=============================================================/
> 
> 
>