Re: Issue #12 proposed resolution

On Sun, Sep 30, 2001 at 10:44:30PM -0400, Mark Baker wrote:
> > 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.
> 
> Or c) expose resource redirection via SOAP.  I think this has merit,
> as resource redirection is applicable with other application protocols,
> even if they currently have no notion of it.  For example, SMTP could
> be extended with SOAP+redirection to support notifying clients of the
> change of somebody's email address (if known).

How is that different from 'a'?


> > 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.
> 
> Excellent point.  While it's true that we can unambiguously
> specify that a SOAP response will use such-and-such a HTTP
> response code, we can't guarantee that any response using
> those response codes will be a SOAP response.

Exactly.


> I'd suggest simpler wording though;
> 
> "A SOAP application MUST NOT use the HTTP response status code
> to infer the presence or absence of a SOAP response."
> 
> This impacts my proposed text from my last message, hopefully
> in an obvious way.

I'd change that to '...presence or substance of a SOAP envelope". 

Cheers,


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

Received on Sunday, 30 September 2001 22:55:10 UTC