Re: Issue: Table 17 (Spec part 2, 7.5.1.2) discrepancies

Henrik Frystyk Nielsen wrote:
>>An alternative proposal is to change table 23 such that env:Sender is  
>>mapped to a HTTP 500 status code. This would then map cleanly 
>>with the  
>>existing table 17. This would have the added advantage of allowing us  
>>to remove table 23 since env:Sender is the only fault not currently  
>>mapped to a 500 status code.
> 
> 
> Hmm, I think we have the same problem regardless of the HTTP status
> code. It may not be too bad to do what Herve suggests, maybe expressing
> it in terms of SOAP messages rather than the content type:

I agree. This doesn't appear in table 20 or table 23, but a responding 
SOAP node may return a 500 Status Code without any SOAP fault in it.

> * * * * * 
> 
> A 400 Bad Request indicates that the message exchange completed
> unsuccessfully:
> 
> 	Instantiated Property		Value
> 	context:FailureReason 		"fail:BadRequest"
> 
> If a SOAP message is included in the HTTP response then the next state
> is "Sending+Receiving", otherwise it is "Fail".
> 
> * * * * *

I like the expression of the next state in terms of SOAP messages (it 
leaves the sending SOAP node free of how to check if the response 
contains or not a SOAP message).

However, in order to be more verbose about the meaning of this response 
code (like for other response codes).
I therefore propose a friendly amendment to Henrik's proposal:

--------
Indicates a problem with either the received HTTP request message or the 
received SOAP message. This operation SHOULD NOT be repeated with the 
same message content.

     Instantiated Property        Value
     context:FailureReason        "fail:BadRequest"

If a SOAP message is included in the HTTP response, the local binding 
instance continues to receive the incomind message. The next state is 
"Sending+Receiving";
Otherwise, the message exchange is regarded as having completed 
unsuccessfully. The next state is "Fail";
--------

> 
> Similarly we can say the same for 500 style responses.
> 
+1.

Hervé.

Received on Tuesday, 17 September 2002 09:29:36 UTC