Re: Issues 12 & 192 (long)

Mark,

I want to draw what I understand to be a clear distinction
between the example that you used in [1] and SOAP's Fault.

Mark Baker previously wrote:
 > This is not a REST specific problem, it's specific to all non-tunnelled
 > uses of an underlying protocol that distinguishes between "data" and
 > "error" on responses (i.e. application protocols).
 >
 > For a real-life example of this, consider the difference between these
 > two URIs.
 >
 > http://www.ibiblio.org/not-a-real-resource
 > http://www.ibiblio.org/404
 >
 > The former is not a real URI, and so it is returned with a 404 status
 > code.  The latter identifies what is returned when a resource is not
 > found, but invoking GET on it returns the *same content* as a 404, but
 > with a 200 response code, ensuring that the browser can bookmark it,
 > cache it, etc..
 >
<snip/>

What occurred to me when thinking about this issue is that
there are NO processing semantics associated with the HTML
content returned in either case for the URI's you cite aside
from the rendering itself. The content of the entity body
returned on a 404 is (potentially) orthogonal to the HTTP status
response. It could just as easily be:

<html><head></head><body><p>Sorry... Have a nice day! :)</p></body>

as:

<html><head></head><body><p>MwaaaHaHaHaHa!</p></body>

as:

<html><head></head><body><p>Doh!(tm)</p></body>

In fact, one of the side issues raised against the original
resolution to issue #12[2] went directly to the point
that it isn't uncommon for proxies and/or the origin server
itself to substitute the entity body returned with something
else. To an HTTP UA (browser), the content of the entity body
of an HTTP 4xx response is completely opaque. Likely, only the
content-type is material to the UA so it can figure out how
it should be rendered, and whether the response was a 200
or a 404 doesn't matter to the rendering software.

The difference I see between your example above and SOAP
is that a SOAP Fault *has* specific semantic *meaning*
*in and of itself* by virtue of the qualified name of the
SOAP Fault EII when it is present as a/the direct child of the
SOAP Body EII. It is that semantic meaning that the
SOAP processor uses to recognize a Fault.

In fact, in practice it would be impossible to know with
any degree of certainty whether the distinction between the
responses of the two URIs you cite was intentional
or unintentional (e.g. a software bug in which the origin
server returned the entity body associated with a 404 HTTP
status response but neglected to set the HTTP status value
accordingly or a mis-configured origin server in which the
administrator placed an incorrect resource URI in the property
that the server uses as the entity body of a 404 response).

In HTTP, the semantics of a fault are present *exclusively*
in the HTTP Status Response Code whereas in SOAP, the
semantics of a fault are (IMO) exclusively embodied in the
SOAP message itself regardless of the underlying protocol used to
transport or transfer the message from node to node.

Okay, so the resolution to issue #12 is (essentially) that the
SOAP HTTP binding will respect this situation, and map SOAP
Fault responses to corresponding/appropriate HTTP Status Code
Responses.

I think that it is only fair that an underlying protocol such as
HTTP NOT modify the semantics of a SOAP message, be it a SOAP Fault
or otherwise.

Cheers,

Chris

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0023.html
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x12

Mark Baker wrote:

> Noah,
> 
> 
>>The second point above makes clear that no binding can make a 
>>determination as to how a SOAP envelope is to be interpreted;
>>
> 
> This statement appears to assume that the binding is somehow a separate
> layer that only sees the envelope given to it by a SOAP processor.  I
> see no such distinction in any of our work, nor do I believe it
> necessary.  I believe we've had this discussion before, with Henrik
> taking the same position that I'm taking (IIRC).  The developer should
> know which application protocol they're using.
> 
> IMO, this is yet another artifact of the chameleon/tunnel distinction.
> 
> 
>>In short, I disagree strongly with the suggestion that any binding would 
>>be the principal determinant of whether a message carried a SOAP fault.  I 
>>do think that a well constructed binding can ensure that there is never 
>>disagreement between what's in the envelope and signals encoded in the 
>>underlying protocol.  In such cases, the binding-specific signal may be 
>>taken as a highly reliable hint.
>>
> 
> I understand.
> 
> Are you ok with the resolution to issue 12?
> 
> MB
>

Received on Wednesday, 27 March 2002 14:39:55 UTC