- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Mon, 21 Feb 2000 14:33:12 -0500
- To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
In a number of your comments, you suggest that we use the expression "blind response" to characterize the 302 that you get back from a redirect reference resource. Can you say more about what you are trying to convey with "blind"? In this message, it looks as if it is supposed to contrast with the 302 you would get back from a non-redirect-reference-resource. How is one of these responses more blind than the other? Or perhaps I'm just off on the wrong track altogether. Thanks. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:47 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.Sec4LastPar 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 Monday, 21 February 2000 14:33:25 UTC