- 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:53 UTC