- From: Ray Whitmer <rayw@netscape.com>
- Date: Thu, 28 Mar 2002 09:37:50 -0800
- To: Christopher Ferris <chris.ferris@sun.com>
- CC: Mark Baker <distobj@acm.org>, xml-dist-app@w3.org
Christopher Ferris wrote: > Mark, > > I'm not interested in allowing a SOAP Fault to be returned > on an HTTP 200 OK response. If it is, then it would have > to be considered a bug and would constitute a > non-interoperable implementation, IMO. The alternative status makes cross-binding routings less efficient because they have to open the envelope to see what HTTP status to return. It also makes every recipient less efficient if he has to open the envelope just to see if there was an error so he can report it. You apparently throwaway all advantage of the hint. > I'm not sure that I agree with Noah that the binding should > be concerning itself with attempting to right the wrong of > another node by comparing the message contents with the response > code. I suppose that it might be free to do so (be liberal in > what you accept and conservative in what you send principle) > but the performance penalty would be a little severe. I believe it should not be required to do this. > My bottom line is a SOAP Fault is a SOAP Fault regardless of > the binding. The faulthint property is just that, a hint. I agree. And generally, the fault is just another message. My applications certainly do not want to have to special-case the HTTP binding and the binding doesn't want to open the envelope. I would be happy to see the alternative status go away entirely, like the special HTTP header, but I haven't followed the whole conversation, so I am certainly missing some compelling argument for an alternative status return that is peculiar to the HTTP binding. Ray Whitmer
Received on Thursday, 28 March 2002 12:37:54 UTC