RE: Issue 192; HTTP binding looks ok

IMO, the resolution of this issue [1][2] seems to be very clear on the
relationship between a SOAP fault and HTTP status codes so I am I not
sure I understand the discussion about which is a hint and which is not.
If the two are not in sync then it is a broken binding implementation
that doesn't conform to the spec. Broken implementations should of
course be called out whenever possible.

Btw, the resolution text in [1][2] doesn't actually seem to be
incorporated into [3] - I have added this to the editor's todo list.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2001Oct/0003.html
[2] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jan/0021.html
[3]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindwa
itstate

>>  I think the current text may be interpreted as the message being
>> authoritative, the binding mandating use of 4xx and 5xx for SOAP
>> Faults and the transition table expecting the two sources of
>> "faultness" of the message to be in accord.
>
>Hmm, that's not my interpretation.  In the transition table we see that
>the HTTP status line (e.g. "HTTP/1.1 200 Ok") contains the information
>with which state transitions are determined, independant of the body.
>
>For example, it says that if you're in the Waiting state, and you see a
>response status line saying "HTTP/1.1 200 Ok", then you change state at
>that point (to "Receiving"), whether or not a SOAP fault follows in the
>body.  This is goodness from a REST POV, but also from a performance
>POV; no party has to wait for the body to arrive and be parsed before
>it can take action on a state change, which means lower latency for
>the entire chain.
>
>>  I think that if we decide that ultimately the message is the
>> authoritative source here, we'll just have to add a text saying 
>> that if there is a discord (fault message on 2xx, non-fault on 
>> 4xx, 5xx) it's the same kind of error like receiving an 
>> incomplete envelope - transport error.
>>  Or if we decide that the faultHint is in fact a faultOverride, 
>> we'll have to clarify that.
>>  I understand that taking the HTTP status code as the
>> authoritative source of this information is very REST but as I
>> still favor the tunneling approach and I haven't seen any clear
>> indication from the group that our HTTP binding will be REST, we
>> probably want to get to a compromise.
>>  Using the HTTP error status codes for SOAP faults is not
>> completely against the tunneling approach, but making the status
>> codes override the message is crossing the line, at least for me.
>>  Maybe the group should decide which approach to take in our
>> binding and accept it fully, or make two HTTP bindings.
>
>I hope it doesn't come to that, but I've raised that possibility
>before.  It still surprises me that we've managed to get as far as we
>have without the group having concensus about the relationship between
>SOAP and the underlying protocols.

Received on Tuesday, 19 March 2002 13:11:14 UTC