Re: Issues 12 & 192 (long)

Mark Baker writes:

>> If the origin server is misconfigured, then that's a 
>> problem that needs fixing.  But as a
>> client, I can't second guess what I'm told.

Grahame Grieve writes:

>> Even if the HTTP status code is 200, if the application
>> receives a fault, it really has little choice in 
>> practice than to interpret it as a fault.

Not quite, IMO.  You're right that the application can't, but the binding 
can.   Specifically, I see the choice as follows:

* The receiving binding knows that it's doing SOAP and could be written to 
check for a mismatch between the HTTP code and the contents of the 
envelope (might be prohibitive from a performance point of view, but 
otherwise OK).    Having seen the mismatch, the binding could infer that 
the origin server was misconfigured, choose not to trust anything from a 
source known to be buggy, and act as if the message had not in fact been 
received at all.  In other words, it could behave in the same manner as if 
its hardware link dropped during reception.  You would then never consider 
the part of the SOAP specification that deals with successful receipt of 
your envelope.

* If the binding declines to check for the mismatch, then as you imply, 
it's the SOAP chapter 2 rules that apply, and the envelope is necessarily 
interpreted as a fault.

In that sense, I believe our current architecture gives you the choice. 
Note that our current HTTP binding does not mandate the check, but you can 
never tell from the outside if someone chooses to do it.  The only symptom 
would be:  "gee, that recipient seems to pretend it never received my 
message every time I send him/her something buggy".  Well, we can never 
insist that a binding succeed at delivering a message, particularly if one 
end of the connection is buggy. 

Does this make sense?

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Grahame Grieve <grahame@kestral.com.au>
Sent by: xml-dist-app-request@w3.org
03/27/2002 03:58 PM

 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Issues 12 & 192 (long)



>
>Hmm, I don't follow.  The difference is that the same entity is
>returned on a 404 versus a 200 response.  If the origin server is
>misconfigured, then that's a problem that needs fixing.  But as a
>client, I can't second guess what I'm told.

right. Even if the HTTP status code is 200, if the application
receives a fault, it really has little choice in practice than to
interpret it as a fault. If one was to insist that a fault was
accompanied by a 4x or 5x response, then the application might
be left in the somewhat ridiculous position of having a fault
that said that the server returned a http OK response but the
soap packet had a fault - instead of simply having the [real]
fault

Grahame

Received on Wednesday, 27 March 2002 17:13:26 UTC