W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Yaron.Redirect.Sec4LastPar

From: Yaron Goland <yarong@Exchange.Microsoft.com>
Date: Thu, 10 Feb 2000 23:46:30 -0800
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A164@BEG.platinum.corp.microsoft.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
The last paragraph of section 4 currently reads:

Since a redirect reference resource is a resource, it can have its own 
properties and body, and methods can be applied to the reference 
resource as well as to its target resource.  The Apply-To-Redirect-Ref 
request header (defined in Section 11.2 below) is provided so that 
referencing-aware clients can control whether an operation is applied to 
the redirect reference resource or to its target resource.  The Apply-
To-Redirect-Ref header can be used with most requests to redirect 
reference resources.  This header is particularly useful with PROPFIND, 
to retrieve the reference resource's own properties.

Given the numerous changes I request in my comments the previous description
is no longer accurate. I also felt that it didn't provide a sufficiently
broad overview of the total functionality provided by redirect resources.
Below I provide several paragraphs that I suggest replace the previous one:

Redirect resources are resources and thus have their own state. However the
default response of a redirect resource to all methods is a 302 (Found). A
mechanism is needed that instructs the redirect resource to handle a method
directly rather than blindly responding to it with a 302 (Found). The
Apply-To-Redirect-Ref request header (defined in Section 11.2 below)
provides such a mechanism. 

For example, if a user issues a PUT request without the
Apply-To-Redirect-Ref request header then the redirect resource will respond
with a 302 (Found). However, if the redirect resource supports PUT and if
the requestor is properly authorized then a PUT issued to a redirect
resource with a Apply-To-Redirect-Ref header will result in the body of the
PUT request being stored for future response to a GET request, assuming the
GET has a Apply-To-Redirect-Ref header.

Please note that it is perfectly legal for the response to a request to a
redirect reference resource with the Apply-To-Redirect-Ref header to result
in a 302 (Found). In this case the 302 (Found) will not be a blind response
but rather will be the correct result of the method. Also note that such a
response would not include a redirect-ref header.
Received on Friday, 11 February 2000 02:46:53 GMT

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