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

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 UTC