Re: Issues 12 & 192 (long)

Hi Chris.  Thanks for thinking more about this.

> 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>

Right!  It's entirely orthogonal.  SOAP shouldn't change that fact.

> 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.

Well, it depends what you mean by "rendering software".  The UA as a
whole cares about the difference, as do intermediaries.

> 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.

Well, nobody's saying that a SOAP Fault on a 200 response is not a
SOAP Fault.  Clearly it is, because of the reasons you give there.
What the chameleons view says is that it must not be processed as a
fault unless the underlying protocol says so.

Even "http://www.ibiblio.org/404" has certain semantic meaning to a
human.  I bet you had to do a double-take at what you were seeing,
because what you saw was something that told you that the page was
missing, but clearly it wasn't missing because you could bookmark it.
The same holds for a Fault on a 200 response, except that now a
machine instead of a user is involved in making the determination.

Assuming that all faults should be processed as faults without first
checking the response code would be the same as a user assuming that a
page that said "not found" was really not found without checking
further into what was going on.

> 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).

Hmm, I don't follow.  The difference is that the same entity is
returned on a 404 versus a 200 response.  If the origin server is
misconfigured, then that's a problem that needs fixing.  But as a
client, I can't second guess what I'm told.

> 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.

Right.

> 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.

Well, the chameleon view is that HTTP *is* the semantics of a SOAP
message transferred with HTTP, assuming we're talking about the same
"semantics" here.  Everything in the current SOAP spec and binding
specification reflects this, thanks to the work of Henrik (though it
could reflect it better in places, re issue 192).  I would hate to
see us introduce any text that introduced inconsistencies.

Can we at least agree that there are two very different uses of SOAP
that we have to support?  If that means doing two HTTP bindings, then so
be it.  But I get the feeling that folks are trying to convince me that
the chameleon view is an invalid one.  And given that my company exists
to build products that use this view (for HTTP), that has me greatly
concerned.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Wednesday, 27 March 2002 15:52:30 UTC