- From: Mark Baker <distobj@acm.org>
- Date: Sun, 30 Sep 2001 22:44:30 -0400 (EDT)
- To: mnot@mnot.net (Mark Nottingham)
- Cc: chris.ferris@Sun.COM (christopher ferris), xml-dist-app@w3.org ('xml-dist-app@w3.org')
> 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