- From: <mrossi@csc.com>
- Date: Mon, 4 Jun 2001 11:22:31 -0400
- To: xml-dist-app@w3.org
Mark, your arguments highlight the fundamental decision that needs to be
made: is XMLP/SOAP a protocol in it's own right (layered on top of HTTP) or
is it an extension of HTTP? However, even in your discussion I don't think
this is clear. You illustrate how HTTP status codes _can_be_ extended (or
used) to accomodate an XMLP/SOAP processor, but the very fact that you're
able to correlate the SOAP faults with HTTP status codes says to me that
SOAP was clearly designed as a separate protocol.
FWIW, I'd prefer that they be layered protocols. This would provide true
independence from HTTP and the ability to map XMLP to other
transfer/transport protocols more cleanly. As for the 'pre-existing
applications' argument, I'd suggest that they treat the HTTP status codes
more carefully. If these applications are assuming some target application
state based on the HTTP status they're just wrong. Also, on the scenario
questions I believe the guideline is that if the request message could not
be delivered for some reason (any reason - like an invalid URL or failure
to start the target app.) than HTTP should return a failure status. If the
message was delivered but a higher-level protocol error ocurred, then HTTP
should return a success status (because it was successful in its mission)
and the higher-level protocol should handle its own error.
BTW - can anyone tell me the difference between a transfer protocol and a
transport protocol? And for what practical purpose would anyone need to
make such a distinction? If at all possible, please don't unnecessarily
overcomplicate life any more than has already been done. Thanks.
Michael A. Rossi
Computer Sciences Corporation
mailto:mrossi@csc.com
856-983-4400 x4911
Mark Baker
<distobj@acm.org> To: xml-dist-app@w3.org
Sent by: cc:
xml-dist-app-requ Subject: Re: Issue #12: HTTP Status Codes 500 v 200
est@w3.org
06/03/01 02:44 AM
My 2c on this issue (I like tackling the tough ones 8-)
SOAP is one way of extending HTTP's (or many other application
protocol's) semantics. It is *not* a layer above HTTP in the same way
that WebDAV isn't a layer on top of HTTP. SOAP and WebDAV are both
extensions of HTTP. SOAP just happens to extend HTTP in a way that HTTP
wasn't expecting (to say the least - and FWIW, this isn't a good thing).
A SOAP fault carried on an HTTP response must therefore use HTTP
semantics as best it can. There are four types of SOAP fault;
- version mismatch
- must understand
- client
- server
The last one clearly maps quite cleanly to a 500. The third one maps
cleanly to 400. (*) The other two aren't as straightforward.
The "Version Mismatch" fault looks a bit like a 505 ("HTTP Version Not
Supported"), but not exactly, since 505 is specific to HTTP versioning,
not SOAP versioning. But I certainly believe that either 500, or a new
5xx code should communicate the intent.
The "Must Understand" fault is quite close to a 417 ("Expectation
Failed" - part of the HTTP 1.1 Expect feature). It's a 4xx ("Client
Error") presumably because if the request hadn't been sent with that
Expect header, you'd be fine. I suggest that either 400 or a new 4xx
status code (not 417, as that's specific to Expect) be used for must
understand as well.
(*) I would normally suggest that using the specific 5xx or 4xx status
codes (rather than 400 and 500) should be used, but as SOAP is trying to
be application-protocol neutral, I can understand its desire not to.
I hope that was helpful.
MB
Received on Monday, 4 June 2001 11:30:52 UTC