Re: Use of HTTP error codes,was :RE: Interesting issues concerningbindings

[christopher ferris <chris.ferris@east.sun.com>]

I concur with David and Dick on this one.

Cheers,

Chris

Dick Brooks wrote:
> 
> 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)
> > >
> > >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard