RE: Use of HTTP error codes,was :RE: Interesting issues concerning bindings

[Dick Brooks <dick@8760.com>]

I completely agree with David's suggestion to use an HTTP 200 status code to
return errors related to the structure/content of an ebXML message.

An early version of SOAP used an HTTP 500 to indicate problems with a SOAP
call frame and many people remarked that this appeared to violate the
layering of HTTP/SOAP. I believe we should avoid using lower layer error
codes/reporting mechanisms to indicate higher layer errors.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Wednesday, December 27, 2000 11:42 AM
> To: 'Henry Lowe'; ebxml-transport@lists.ebxml.org
> Subject: Use of HTTP error codes, was :RE: Interesting issues concerning
> bindings
>
>
> Message-id:
>  <63751F9A4BBBD411A6E000508BA5831F0224A6@c1plenaexm03.commerceone.com>
> MIME-version: 1.0
> X-Mailer: Internet Mail Service (5.5.2652.78)
> Content-type: text/plain
> List-Owner: <mailto:ebxml-transport-help@lists.ebxml.org>
> List-Post: <mailto:ebxml-transport@lists.ebxml.org>
> List-Subscribe:
> <mailto:ebxml-transport-request@lists.ebxml.org?body=subscribe>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> I've been looking at this thread too from the perspective of HTTP error
> codes. Currently the specification is not clear about what error codes
> should be used. My suggestion is that we always return a 200 code (OK)
> unless there is an error in the HTTP header in which case we return a 500.
>
> This means that even if there are errors in the MIME packaging or in the
> ebXML header, the HTTP response is always a 200.
>
> Does this make sense ... I'm not a MIME expert?
>
> David
>
> -----Original Message-----
> From: Henry Lowe [mailto:hlowe@omg.org]
> Sent: Wednesday, December 20, 2000 9:44 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Interesting issues concerning bindings
>
>
> Hi,
>
> As perhaps not all of you are on the XP list, I thought I'd forward
> this message as it has some interesting use cases which impact bindings
> to underlying transport protocols.
>
> Strictly FYI -- I'm not pushing this, but they are things we may want
> to do, too.
>
> Best regards,
> Henry
> ---------------------------
> >Resent-Date: Wed, 20 Dec 2000 09:23:14 -0500 (EST)
> >From: "John Wilson" <tug@wilson.co.uk>
> >To: "'Kevin Koch'" <Kevin.Koch@realLegal.com>, <xml-dist-app@w3.org>
> >Date: Wed, 20 Dec 2000 14:22:40 -0000
> >Organization: The Wilson Partnership
> >X-Mailer: Microsoft Outlook Express 5.00.2314.1300
> >Subject: Re: SOAP spec.: HTTP binding
> >Resent-From: xml-dist-app@w3.org
> >X-Mailing-List: <xml-dist-app@w3.org> archive/latest/1142
> >X-Loop: xml-dist-app@w3.org
> >Sender: xml-dist-app-request@w3.org
> >Resent-Sender: xml-dist-app-request@w3.org
> >List-Id: <xml-dist-app.w3.org>
> >List-Help: <http://www.w3.org/Mail/>
> >List-Unsubscribe:
> <mailto:xml-dist-app-request@w3.org?subject=unsubscribe>
> >
> >
> >----- Original Message -----
> >From: Andy Neilson <aneilson@webplan.com>
> >To: 'Kevin Koch' <Kevin.Koch@realLegal.com>; <xml-dist-app@w3.org>
> >Sent: 18 December 2000 23:03
> >Subject: RE: SOAP spec.: HTTP binding
> >
> >
> >> I agree with this comment. The requirement that the HTTP
> binding specify
> >the
> >> success or failure of the request as the HTTP status limits seems to
> >presume
> >> a particular processing model in which you know the overall success or
> >> failure status before you start returning any response (i.e., you are
> >using
> >> an in-memory model like a DOM).
> >>
> >> I have been developing SOAP processors where:
> >>   - performance is critical
> >>   - memory must be constrained, and
> >>   - the request and/or response size may be very large.
> >
> >I have this problem too. Currently neither XML-RPC nor SOAP provide
> >satisfactory solutions.
> >
> >There are at least two situations in which a server may want to start to
> >send the response before having read the while of the request:
> >
> >1/ In memory constrained situations
> >
> >2/ In performance critical applications where it is necessary to minimise
> >latency.
> >
> >As well as issues with HTTP result codes there are more general
> lacunae in
> >the SOAP spec:
> >
> >a) There is no way of reporting the presence of a value in a
> response which
> >the server is unwilling or unable to represent without returning a Fault
> and
> >it is impossible to return a Fault if the result has been partially sent.
> >
> >b) It is impossible to tidily abort a response once part of it has been
> >sent.
> >
> >One way that case a) turns up is when the  response contains an
> object that
> >the server doesn't know how to serialise. It's possible that this isn't a
> >problem to the client. However the only option the server has is
> to return
> a
> >Fault. However the server has to examine the whole of the response to see
> if
> >such a problem exists before it can send the first character of the SOAP
> >response.
> >
> >If SOAP had a way of embedding a non fatal error in a response then it
> would
> >be a solution to case a). (i.e. an element that said "I didn't understand
> >this bit of the response, if it's a problem for you then this is
> a failure,
> >otherwise ignore it")
> >
> >If SOAP had what is effectively an exception mechanism (i.e. en exception
> >element followed by all the close element tags to make the document well
> >formed) then this would be a solution to case b).
> >
> >In the absence of any help from the SOAP spec the only solution to these
> >problems that I can think of is for the server to brutally close the
> >connection in mid response - this is not really desirable;)
> >
> >It is possible that these issues arise from application domains that SOAP
> is
> >not intended to address, of course.
> >
> >My own inclination is to look at something build on a subset of XML-RPC
> >(with some error reporting extensions) for highly memory constrained
> >applications.
> >
> >John Wilson
> >The Wilson Partnership
> >5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
> >+44 1296 641072, +44 7976 611010(mobile), +44 1296 641874(fax)
> >
> >