Re: Issue #12 proposed resolution

I understand the concerns about compliance, but I think that picking
out things that seem like a good idea to us at the time is the road
to hell; it encourages people to implement without looking at the
specs for the underlying transports, and our selection of the
features to highlight can only be arbitrary.

Something like:

  Implementations of this binding MUST be compliant with the
  requirements of either RFC2616 [HTTP/1.1] or RFC1945 [HTTP/1.0], or
  later Standards-track specifications which obsolete them.

should be near the top of the binding definition.


Regarding redirection, we're in somewhat of an interesting situation.
I *think* the WG's intent is to support automagic redirection.
However, there is langugage to this effect in the definitions of 301,
302 and 307;

  If the 307 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect
  the request unless it can be confirmed by the user, since this
  might change the conditions under which the request was issued.
  
In other words, because we use POST, client applications cannot be
HTTP compliant and automatically redirect SOAP requests (unless you
take great license with 'confirmed by the user').

With this in mind, we can do one of two things; 

a) Disallow the use of 3xx HTTP redirection, and rely on a SOAP
   Module, Fault or similar to enable redirection.

b) Carefully craft wording to the effect that SOAP clients should
   assume user confirmation.

In either case, we probably do need explanatory language in the spec.
I'm slightly in favour of 'a' at this point.


Also, regarding status codes; can we insert some language to the
effect that SOAP Applications MUST NOT use status codes as a means of
determining the content of a SOAP message? I.e., see a 5xx, and
blindly act as if it contains a Fault? I think something to the
effect of:

  If there is contention between the HTTP semantics of a message
  (e.g., status code) and information in the SOAP Envelope, SOAP
  Applications MUST act upon the Envelope content.

should do the trick.



On Fri, Sep 28, 2001 at 02:06:53PM -0400, christopher ferris wrote:
> 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
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Friday, 28 September 2001 15:50:22 UTC