- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 12 Nov 2004 14:47:01 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: Hugo Haas <hugo@w3.org>, www-ws-desc@w3.org, xml-dist-app@w3.org
- Message-ID: <OF534A9B8A.B08CB588-ON85256F4A.006C2D19@lotus.com>
Hmm. So an interesting question is whether the HTTP binding ever sends a 202. I find the table in 7.5.1.2 somewhat ambiguous. It contains the following: Status Code Reason phrase Significance/Action NextState 2xx Successful 200 OK The response message follows in HTTP response entity body. Start making an abstraction of the response message available in http://www.w3.org/2003/05/soap/mep/InboundMessage . "Sending+Receiving" or "Receiving" 3xx Redirection The requested resource has moved and the HTTP request SHOULD be retried using the URI carried in the associated Location header field as the new value for the http://www.w3.org/2003/05/soap/mep/ImmediateDestination property. "Init" 4xx Client Error 400 Bad Request Indicates a problem with the received HTTP request message. "Sending+Receiving", "Receiving" or "Fail" 401 Unauthorized Indicates that the HTTP request requires authorization. If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the message exchange is regarded as having completed unsuccessfully. "Requesting" or "Fail" 405 Method not allowed Indicates that the peer HTTP server does not support the requested HTTP method at the given request URI. The message exchange is regarded as having completed unsuccessfully. "Fail" 415 Unsupported Media Type Indicates that the peer HTTP server does not support the Content-type used to encode the request message. The message exchange is regarded as having completed unsuccessfully. "Fail" 5xx Server Error 500 Internal Server Error Indicates a server problem or a problem with the received request "Sending+Receiving", "Receiving" or "Fail" I think the 2xx is intended as a separator, and the only response sent by the binding is 200. I agree that we could have called for 202, in which case we should have clarified how the state machines at both ends continue to implement the Request/Response MEP from that point. If my earlier note is correct, an explicit SOAP header could be created calling for the 202 as you suggest, the spec for which would fill in the missing pieces as to how the binding state machines would proceed from there. Is 202 really an appropriate response if you are going to give an application response to the post using some other out-of-band means? I suppose so. I still think all this is a bit unsatisfying, primarily because you're trying to preserve the appearance of use of the SOAP HTTP binding when in fact there's no interop with unenhanced implementations. That being the case, I think it's more appropriate to admit that you're doing a new and to some degree non-interoperable binding. I accept your reading that 202 makes use of HTTP at least semi-appropriate. Thanks. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- Mark Baker <distobj@acm.org> 11/12/2004 02:32 PM To: noah_mendelsohn@us.ibm.com cc: Hugo Haas <hugo@w3.org>, www-ws-desc@w3.org, xml-dist-app@w3.org Subject: Re: Seeking clarification about the use of the HTTP binding On Fri, Nov 12, 2004 at 01:42:04PM -0500, noah_mendelsohn@us.ibm.com wrote: > Finally, I think there's a case to be made that this is a significant > misuse of HTTP itself, which has a pretty strong notion of > request/response on a POST (you couldn't send the header on a GET.) I don't think it's quite that strong, Noah. I believe that the 202 "Accepted" response provides the desired "out" here, by being "intentionally non-committal". I've used it myself, on occasion, for exactly the scenario described. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Friday, 12 November 2004 19:48:52 UTC