- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 24 Apr 2002 15:42:39 +0100
- To: "'Mark Baker'" <distobj@acm.org>, Christopher Ferris <chris.ferris@sun.com>
- Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, noah_mendelsohn@us.ibm.com, henrikn@microsoft.com, john_ibbotson@uk.ibm.com, marc.hadley@uk.sun.com, martin.gudgin@btconnect.com, moreau@crf.canon.fr, xml-dist-app@w3.org
Hi Mark, > On Wed, Apr 24, 2002 at 07:47:58AM -0400, Christopher Ferris wrote: > > Maybe it just needs to be clearer as to the nature of the > > entity body that MAY appear in the 202 response. It MAY > > be a SOAP message detailing for the requester when it might > > expect the result to be ready. It MAY be an acknowledgment > > message such as might be used for reliable messaging > > for purposes of nonrepudiation such as defined by ebXML. > > I agree. It might also not be a SOAP response. :-) > > I would suggest that it NOT be removed just clarified. > > The problem with not removing it is that there are certain assumptions > made by the MEP and HTTP binding with respect to the SOAP processing > model. The big one is that if you get a response, that it is a result > of the SOAP Envelope being processed. I'm not sure that I really buy that... I think that the assumption that the MEP and HTTP binding make is that the response message is causally dependent on the request message - certainly, I think that's the only assumption I'd be comfortable with. > So in order to be able to support > a 202 response in this binding, we'd have to create a MEP that exposed > the difference between a response that implies the SOAP processing model > was obeyed, and another type of response which implies that > it was not. So I think what was in my mind when drafting table 11 was the philosophy about classes of status codes, from RFC 2616 section 6.1.1: HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. which might allow me to exhibit a degree of ignorance about the specific meaning of 202 and treat it "as being equivalent to x00 (200 in this case)." > I hope you agree that it's a bit late for that! 8-) I don't think I would want to develop MEPs with 'minor' differences. I think that there is scope (and possibly time) to add a property that account for the disposition of the exchange eg. processing complete, pending, faulted... . Might be a more generic form of context:FailureReason, which elaborates exchanges that fail - instead, or aswell as, something that elaborates on degrees of success. > I apologize to Stuart for not catching this earlier, but I wouldn't have > caught it at all if not for Noah's message that prompted me to check how > the binding handles 202. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@planetfred.com > http://www.markbaker.ca http://www.planetfred.com Regards Stuart
Received on Wednesday, 24 April 2002 10:44:17 UTC