W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

Redirect References Spec: "Passthrough" Header

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Wed, 25 Aug 1999 11:19:20 -0400
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24412@crte147.wc.eso.mc.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
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
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580
Received on Wednesday, 25 August 1999 11:19:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:51 GMT