Re: Issue #12 proposed resolution

> 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').

Henrik and I discussed this exact issue a while ago off-line.
IIRC, he suggested that the MUST NOT was likely too strong.
I admitted to being surprised by it too.

> 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.

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).

> 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.

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.

MB

Received on Sunday, 30 September 2001 22:42:23 UTC