Returning SOAP fault via HTTP 200 is a common practice

[jkingdon]

In Savon 0.8.5, checking for a SOAP fault requires that a SOAP fault be sent with a 500 error code. It is true that http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html#HTTP_Server_Error_Status_Codes requires that the status code be 500. However, it seems to be fairly common practice to send it with 200. This is especially to work around flash bugginess (see http://bugs.php.net/bug.php?id=43507 for example).

One possible solution is just to revert the portion of commit 2526703 which checks for the status (keeping the part which switches from regexp to substring matching). Another would be to create a setting, which people could enable by calling client.allow_200_soap_fault or something, based on whether they need to deal with servers who return 200, and people who don't call that method would not incur the performance cost. I've taken a bit of a stab at convincing the people running my server to use 500, but I'm not sure that's going so well and seems unlikely to be a general solution (based on googling, I appear to be far from the only one in this boat).

[jkingdon]

For SOAP 1.2, the W3C spec specifies a status code of either 400 or 500 depending on the kind of fault. See table 20 at http://www.w3.org/TR/soap12-part2/#tabresstatereccodes

[rubiii]

trusted implementations to follow the spec and it backfired once again. this is downright ridiculous. thank you very much for reporting the problem. i'll try to fix this asap.

[jkingdon]

This is no longer an issue for me (our SOAP server has changed to 500, which I guess is the default in Intersystems Caché 2012.2 but not earlier versions). How much of an issue this is elsewhere I couldn't really say. I tend to like the idea of insisting on a spec, or requiring syntactic vinegar to violate it, as a way of encouraging compliance, but this is a tricky balance and it doesn't pay to be too strict about such things.

[jkingdon]

Rumors that our server was fixed were exaggerated. Here's a simple patch to make it configurable: https://github.com/rubiii/savon/pull/156
but I'm open to other solutions.

[TafThorne]

Looks like we will need this setting too. Although i147 fixed our initial problem we also found that our server was (wrongly) generating Status 200. I am now in the process of trying to get people to change it to generate status 500 but the fact that the system is currently working means that some people see it as option to be following a specification.

[TafThorne]

I would be in favour of making it configurable as suggested in i156 and mentioning in the code comments that people who disable the checking for status 400 or 500 will suffer a performance hit and should look at better complying by not returning status 200. Whether the default is to do things as the spec suggested (which should nudge people to comply, but might generate some questions) or to just do things the slow way (which will work 100% but might get people asking why things take so long) is up to the author I would say.

[rubiii]

this is a duplicate of issue 147 (which should be fixed by now).