- From: christopher ferris <chris.ferris@Sun.COM>
- Date: Fri, 28 Sep 2001 14:06:53 -0400
- To: Mark Baker <distobj@acm.org>
- CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Mark, Please see my comments/responses below. Cheers, Chris Mark Baker wrote: > > Hi Chris, > > Two issues for you. > > > As agreed on the call, I have removed reference to 201, 203, 205 and > > 206. I have also changed the SHALL to a MAY in regards to 405 and > > I have modified 500 to reflect its use for cases other than those described > > in section 6.3.2 (4xx Client). > > Issue 1; > > 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. > If so, I can buy that, but I'd suggest that 202, 405, and 415 don't need > that explanation (no biggie though). Actually, in the context of the SOAP/HTTP "default" binding, I think that they do. > > It's good that there's no mention in your proposal of disallowing other > status codes, but as with 3xx, I'd suggest that explicitly stating that > fact would be useful to implementors. That's my main concern here really - > that developers don't assume that other status codes can't be used. I think that's where we're at now, trying to figure out if we say this explicitly, or leave it to the imagination of the reader. I favor explicitly saying something, as I believe does Stuart and others. 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. > > Issue 2; > > In my original proposal[1], I had a footnote; > > "(*) I would normally suggest that using the specific 5xx or 4xx status > codes (rather than 400 and 500) should be used, but as SOAP is trying to > be application-protocol neutral, I can understand its desire not to." > > I believe it's still important for SOAP developers that they *not* be > forced into specifying an HTTP response code. I therefore think it's > important that a default response code be defined for each type of SOAP > fault. I was imagining that the code would look something like this; > > SoapFault f = new SoapFault( SoapFault.CLIENT_FAULT, "you did \ > something wrong" ); > // f.statusCode initialized to 400 above, but hidden from developer > soapConnection.setResponse( f ); > > and that this could be used by the majority of developers, and would > return a 400 (client fault) status code. Alternately, developers > requiring specifying more fine grained response codes could do this; > > SoapFault f = new SoapFault( 405, "don't know how to do that" ); > soapConnection.setResponse( f ); > > 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. > > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0017.html > > MB
Received on Friday, 28 September 2001 14:06:54 UTC