- From: Grahame Grieve <grahame@kestral.com.au>
- Date: Mon, 01 Apr 2002 22:30:14 +1000
- To: xml-dist-app@w3.org
At 07:43 PM 31/03/2002 -0500, you wrote: >Looks good Noah. One minor comment; > > > 2a. Regardless of the envelope, the HTTP code should take precedence. A > > SOAP fault received with a 200 cannot be a fault...though I'm not quite > > sure what it is then! (Mark Baker) > >It's still a fault, it's just not processed as one. Like when HTML >is sent as text/plain; it's still HTML, just not processed as HTML. sorry - I don't understand. Since HTTP says it's not a fault, well the application will just pretend that it wasn't. how does that make sense? This whole thing seems a bit strange to me. We insist that a SOAP fault be represented as a HTTP 500 (or 5xx?) since somehow that is deemed to be "better". So are we also going to insist that all the other HTTP response codes be used appropriately. For instance, I might insist that if a method response simply consists of a confirmation of message receipt, with no other information, then the HTTP status code should be 202, whereas normally, it should be 200. Also, how could one implement SOAP-on-HTTP but by using a generic HTTP library? how can one not model it as "tunneling" when actually doing the implementation? Grahame
Received on Monday, 1 April 2002 07:38:33 UTC