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

["Burdett, David" <david.burdett@commerceone.com>]

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)
>
>