Re: Issues 12 & 192 (long)

Mark Baker wrote:

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


And indeed, it is not.


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


Being able to bookmark it is a pretty obscure means of achieving
understanding.


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


Depends on what "you're being told". Most users will never see the
HTTP response, but they'll surely see the rendered entity body.


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


I'm in agreement here. I have no problems with respecting HTTP
semantics. However, I do have a problem with treating a SOAP Fault
returned on a 200 OK as anything other than a SOAP Fault. I think
that this MUST constitute an error in implementation.


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

Received on Wednesday, 27 March 2002 16:27:16 UTC