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

Re: Issue #12 proposed resolution

From: Mark Baker <distobj@acm.org>
Date: Fri, 28 Sep 2001 16:31:15 -0400 (EDT)
Message-Id: <200109282031.QAA01071@markbaker.ca>
To: chris.ferris@Sun.COM (christopher ferris)
Cc: xml-dist-app@w3.org ('xml-dist-app@w3.org')
> > I'm quite curious to hear why the references to those other response
> > codes were removed.  Is it because you felt that only these response codes
> > needed an additional explanation in the context of their use with SOAP?
> The WG took the position (mostly) that only those status codes that
> had SOAP-specific meaning would be mentioned. 

Hmm, ok.  But in that case I'd suggest that most of the 200s are missing.
Just looking through all the HTTP response codes now, the only ones
that don't look appropriate is 206, and maybe 205.

> My thinking is that most readers of the SOAP spec will NOT have read the
> HTTP RFC. Providing them with a hint/guidance is useful IMO.


> > In [1], I'm suggesting what that *default* fault response codes should
> > be.  Obviously the default for a good SOAP response should be 200, but
> > using a mechanism similar to what's above, developers should be able to
> > specify more fine grained 2xx response codes.
> I understand where you're coming from, but my thinking is that if you
> have (as I do) any expectation of interoperability, you need to say what
> is required so that an implementation can know what to expect. 

I thought I was saying that! 8-)  Here, let me formalize it;

For the HTTP binding;

A SOAP processor MUST return a default HTTP response code 200
upon the successful processing of the SOAP request, a 400 response
code upon the failure of a SOAP request due to a problem at the
client, and a 500 response code upon the failure of a SOAP request
due to problems on the server.  A SOAP processor MUST only rely on
the most significant digit of the HTTP response codes for determining
the success or failure of the request, permitting the communication
of more fine grained status code information to SOAP processors that
wish to use it.

Not for the spec, but just to describe what I had in mind with
an API;

A SOAP library MAY provide developers the option to specify more
specific HTTP response codes, but in doing so SHOULD ensure that the
most significant digit of the response code being set matches the
most significant digit of the default response code for the type of
response (when that information is available to it), as described
in the previous sentence.

e.g. if in code, I did this;

   SoapResponse r = new SoapResponse( myResponse );
// "r"'s response code is now set to 200


   r.setResponseCode( 400 ); // would throw an exception
   r.setResponseCode( 201 ); // would be ok

How's that?

Received on Friday, 28 September 2001 16:29:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC