Re: rec33 proposal

Yves,

This looks good to me.

WRT redirect handling; HTTP requires that requests not be  
automatically retried *unless* it is confirmed by the user. For  
example,  the W3C's Amaya browser allows you to list the domains for  
which it should automatically follow redirections on PUT. Perhaps a  
similar approach could be taken here; e.g., a redirect is an  
exceptional condition *unless* the client is explicitly configured to  
automatically redirect.

I'm not sure how to express that in the state machine, but then I was  
never a big fan of the abstract model...


On 11/10/2005, at 9:31 AM, Yves Lafon wrote:

>
> First, the REC is ok with the "common" 3xx codes used for redirect,  
> 301, 302 and 307.
>
> From table 17, in part2:
>
> Status Code:
> 3xx
>
> Reason Phrase:
> Redirection
>
> Significance/Action:
> The requested resource has moved and the HTTP request SHOULD be  
> retried using the URI carried in the associated Location header  
> field as the new value for the http://www.w3.org/2003/05/soap/mep/ 
> ImmediateDestination property.
>
> next state:
> "Init"
>
> Here is a quote from rfc2616 regarding 301 (it applies also to 302  
> and 307):
> <<<
>    If the 301 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect  
> the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.
>
>>>>
>>>>
>
> As the redirect handling is done at the SOAP level, everything is OK.
>
> For 304 Not modified, it means that the response was already  
> cached, so I expect that the reply at the SOAP layer might be given  
> by the underlying layer (but we can explicitely say that with text  
> like
> "If the implementation want to cache responses following the  
> indication of the HTTP headers, and performs conditional request,  
> then the implementation MUST surface the SOAP message at the SOAP  
> level in case of a 304 HTTP response" ).
>
> 305 seems obvious as well.
>
> Now for 303.
>
> 303 is different as it changes the kind of HTTP request to a GET,  
> and also there is no longer an entity body sent in the subsequent  
> request.
> The good thing is that the state machine is the same regardless of  
> the MEP defined, so we are not running in the issue of having to  
> switch state machine there, which is what I feard originally.
>
> So the suggested course of action for 303 is to add an entry in  
> table 17
>
> <ProposedText>
>
> Status Code:
> 303
>
> Reason Phrase:
> See Other
>
> Significance/Action:
> The requested resource has moved and the HTTP request SHOULD be  
> retried using the URI carried in the associated Location header  
> field as the new value for the http://www.w3.org/2003/05/soap/mep/ 
> ImmediateDestination property. The value of http://www.w3.org/ 
> 2003/05/soap/features/web-method/Method is changed to "GET", the  
> value of http://www.w3.org/2003/05/soap/mep/OutboundMessage is set  
> to null.
>
> Next Step:
> Init
>
> </ProposedText>
>
> The next state is "Init" as the HTTP request has to be  
> reconstructed with the new property values.
>
>
> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."
>
>


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems