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

Re: Summarizing the last 192 discussion

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
Message-ID: <20020401113059.A6693@www.markbaker.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT