W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: another approach to status codes, etc. in HTTP binding

From: Mark Baker <distobj@acm.org>
Date: Wed, 18 Jul 2001 17:35:11 -0400
Message-Id: <200107182135.RAA01708@mail3.magma.ca>
To: eamon.otuathail@clipcode.com, David Crowley <dcrowley@scitegic.com>
CC: xml-dist-app@w3.org
Thanks Eamon.  That sounds like the right choice for using BEEP, but BEEP isn't an application protocol so the design 
of the bindings is *very* different.

If a SOAP binding to APEX (an application protocol) were done, the issues would be similar as for HTTP.

MB

7/18/2001 5:11:34 PM, "Eamon O'Tuathail" <eamon.otuathail@clipcode.com> wrote:

>
>
>From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
>Behalf Of David Crowley
>
>>> SOAP errors are communicated with SOAP Fault.  HTTP errors are
>>> communicated with HTTP status codes.
>
>David,
>
>FYI, in the SOAP over BEEP binding, this same issue arises - SOAP have SOAP
>Fault errors, and what transfers it, BEEP, has BEEP ERR messages.
>
>The solution there was to use BEEP ERR messages for things that went wrong
>at the BEEP level only. BEEP considers the SOAP envelope it carries as
>opaque, and does not peek inside. So it does not know, and does not need to
>know, that a particular envelope actually contains a SOAP fault.
>
>In most implementations, the pieces of code that handle the transfer
>protocol and the SOAP processing are distinct, so as you suggest, having
>distinct errors for them seems appropriate.
>
>Eamon
>
>
Received on Wednesday, 18 July 2001 17:35:12 GMT

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