RE: Yaron.Redirect.Sec4LastPar

The term "blind response" is meant to convey the idea that the redirect
resource, once it determined that there isn't a pass-through header,
blindly, without any thought, responds with a 302.

I introduce the "blind response" phrase to pull away from the "automatic
response" phrase because the "automatic response" phrase  gives me the idea
that rather than return a 302 the resource will actually act as a sort of
proxy for the request and forward it itself to the target and return the
response.

I'm just trying to avoid confusing the reader.


> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Mon, February 21, 2000 11:33 AM
> To: Yaron Goland; w3c-dist-auth@w3.org
> Subject: RE: Yaron.Redirect.Sec4LastPar
> 
> 
> 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 Thursday, 24 February 2000 01:36:35 UTC