- From: Mark Baker <distobj@acm.org>
- Date: Fri, 28 Sep 2001 16:31:15 -0400 (EDT)
- 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. +1 > > 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 then; r.setResponseCode( 400 ); // would throw an exception r.setResponseCode( 201 ); // would be ok How's that? MB
Received on Friday, 28 September 2001 16:29:09 UTC