Re: [soapbuilders] HTTP Error codes
- There is also a fifth situation. 400 Bad Method + error message (not
SOAP). The only way you can be reasonably sure that a SOAP message is
being returned is if the result code is 200. IMHO the problem here is that
a SOAP errors should not show up as a transport error. SOAP has it's way
of dealing with errors using SOAPFault. HTTP has it's way of dealing with
errors with the server return codes. And the two shouldn't be
mixed. Because when you do, you end up in the strange situation you have
now where if you get back a 500 code, sometimes you can parse the response
and other times you can't. So SOAP has to know about the transport and the
transport has to know about SOAP. I'm sure there was good reasoning behind
the spec saying that 500 should be returned. Maybe someone has some
At 09:33 AM 2/8/2001 -0800, you wrote:
>I'd like to talk about error codes from HTTP SOAP servers.
>As far as I remember 4 situation is possible. There is no questions
>about first two. There were several long discussions about what
>return with SOAP Fault, 200 or 500 and as I remember consensus was
>for 200OK, but most toolkits return 500 or even 400? from Xmethods
>(Tony, is it ApacheSOAP or XMethod's router?).
> 1. 200 OK + SOAP message (normal result)
> 2. 500 Server Error + error message (not SOAP)
> 3a. 500 Server Error + SOAP message (Fault result)
> 3b. 400 Bad Method + SOAP message (Fault result)
> 4. 200 OK + SOAP message (Fault result)
>So, what's your take on it and should we stay we 200OK or will return
>500 on SOAP Fault? Do we need to accept 400 or it's something that
>could be changed on server side?
>Best wishes, Paul.