W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Summarizing the last 192 discussion

From: Ray Whitmer <rayw@netscape.com>
Date: Thu, 28 Mar 2002 09:37:50 -0800
Message-ID: <3CA354EE.9090903@netscape.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC