- From: Mark Baker <mark.baker@sympatico.ca>
- Date: Mon, 1 Apr 2002 11:30:59 -0500
- To: Grahame Grieve <grahame@kestral.com.au>
- Cc: xml-dist-app@w3.org
Grahame, > 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? Because that's what "the application of HTTP" is; if you do a POST, and it doesn't work, that's signalled with a 4xx or 5xx response code. If you received a SOAP fault described as text/plain, is that still a fault? Sure, it's just not processed as one. > 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. There's no need to insist, IMO. HTTP gives special significance to the first digit of the response code, and we can work with just that. If implementations want to use more specific codes, they're welcome to. > 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? Hmm, your first question answers the second one IMO; use a SOAP library which produces an envelope which you can then pass to the HTTP library. Ditto for the reverse. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Monday, 1 April 2002 11:25:28 UTC