RE: Redirect References Spec: "Passthrough" Header

Comments in <js> </js> tags below.

> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Wednesday, August 25, 1999 1:15 PM
> To: Slein, Judith A
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Redirect References Spec: "Passthrough" Header
> 
> 
> 
> 
> 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? 

<js>
You can *never* use redirect references to operate directly on target
resources.  That's what direct references were, but they have been removed
from the spec.

There are only 2 behaviors you can get out of redirect references: 302 or
operate on the reference itself.

For most methods the default behavior is 302, and you have to use
Passthrough: F to have the method apply to the reference.  For a few
methods, the default behavior is apply to the reference, and you have to use
Passthrough: T to get a 302.

So what are the reasons for insisting that methods sent to redirect
references never get applied directly to the target resource?

1. Even though direct references have been removed from the spec, we want to
keep a clean distinction between direct and redirect references.  We may
decide to restore direct references some day.

2. It's a design goal that redirect references be simple to implement.  They
should require little more than the 302 mechanism already implemented.  In
particular, servers never have to resolve the reference.

2a. Servers never have to act as proxies in order to implement redirect
references.  We want to be sure that redirect references can be used for
cross-server access to the target resource.  This is especially important
because it is unlikely that cross-server bindings will be implemented.  So
we need some sort of referencing that is sure to be usable across servers,
and redirect references fill that gap -- provided that we never require the
server to apply a method to the target resource.
</js>

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

<js>
I think things are less complicated than you fear.

I think what you really are asking is separate from the Passthrough: issue.
It's about whether we should ever say that behavior is different depending
upon whether (1) the Request-URI identifies a redirect reference, or whether
(2) the Request-URI identifies a collection that turns out to contain a
redirect reference.  There is only one case where we do that: COPY.  I agree
with you that this is bad.  I think we should say either 

(1) that the default behavior of COPY is to apply to the reference, whether
the Request-URI identifies the reference or the reference is a member of the
collection identified by the Request-URI, or 

(2) that the default behavior of COPY is to respond with a 302, whether the
Request-URI identifies the reference or the reference is a member of the
collection identified by the Request-URI.

Here's a table of all the default behaviors for the different methods.  That
is, in the absence of a Passthrough: header, this is what happens.

               Request-URI is redirect ref       Redirect Ref encountered
                                                 while processing a
collection

PROPFIND       302                               302
COPY           302                               Apply to reference
DELETE         Apply to reference                Apply to reference
MOVE           Apply to reference                Apply to reference
LOCK           Apply to reference                Apply to reference
GET            302                               N/A
HEAD           302                               N/A
PUT            302                               N/A
POST           302                               N/A
OPTIONS        302                               N/A
PROPPATCH      302                               N/A
MKCOL          302                               N/A
MKREF          302                               N/A
BIND           302                               N/A
ORDERPATCH     302                               N/A
</js>

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

Received on Thursday, 26 August 1999 10:52:51 UTC