Re: Issue 192 & R803

Mark,


Mark Baker wrote:

> Chris, thanks for putting this together.
> 
> 
>>Unless there's been a drastic change to SOAP in the last
>>couple of days, the contents of the SOAP Body element are
>>targetted implicitly at the ultimate SOAP receiver node,
>>not at intermediaries. An intermediary can peek at the
>>contents, but it is NOT supposed to "process" the contents
>>in the SOAP sense.
>>
> 
> Well, the SOAP processing model only applies to SOAP intermediaries, no?
> We can't retroactively go about saying that non-SOAP HTTP intermediaries
> have to follow these rules.


Non-SOAP HTTP intermediaries have no business with the SOAP envelope
in the entity body except as an opaque blob that happens to be
of some media type. If they go beyond that, then IMO, they are
SOAP intermediaries.


> 
> 
>>An intermediary SOAP node by definition MUST NOT assume
>>the role of http://www.w3.org/.../role/ultimateReceiver.
>>
>> From section 2.2 of SOAP 1.2 Part 1[1]:
>>
>>     "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver"
>>        To establish itself as an ultimate SOAP receiver a SOAP node MUST
>>        act in this role. SOAP intermediaries MUST NOT act in this role.
>>
>> From section 2.3 of SOAP 1.2 Part 1:
>>
>>     The ultimate SOAP receiver MUST process the message body. The SOAP
>>     message path for that message ends at its ultimate SOAP receiver.
>>
>> From section 2.4 of SOAP 1.2 Part 1:
>>     Mandatory blocks MUST be presumed to somehow modify the semantics of
>>     other headers or body elements. Therefore, for every mandatory SOAP
>>     header block targeted to a node, that node MUST either process the
>>     block or not process the SOAP message at all, and instead generate a
>>     fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).
>>
>> From section 2.5 of SOAP 1.2 Part 1:
>>
>>     An ultimate SOAP receiver MUST correctly process the immediate
>>     children of the SOAP body (see 5.3 SOAP Body).
>>
> 
> Right, all that looks fine to me.
> 
> 
>>Thus, if you want to modify the semantics of SOAP Fault EII as
>>child of the SOAP Body EII, you must then include a SOAP Header
>>extension (block) that changes its semantic meaning to be
>>something other than a SOAP Fault and target that SOAP Header
>>extension at the SOAP node operating in the .../ultimateReceiver
>>role.
>>
> 
> I don't follow.  The processing model doesn't care whether the received
> envelope contains a fault or not.  This is consistent with the
> chameleon use.


That's not how I read section 2.5. A SOAP intermediary isn't concerned
with the SOAP Body EII and its contents, to be sure, but the
SOAP node operating in the .../ultimateReceiver role MUST be capable
of "correctly processing" the contents of the SOAP Body EII which I
interpret as meaning, if the child of the SOAP Body EII is a SOAP
Fault EII, it is a fault, and I process it as such unless there
is some SOAP Header block telling me otherwise. That is the SOAP
processing model as I understand it. The SOAP Processing model
doesn't say anything about bells and whistles in the underlying
protocol effecting the SOAP processing of the received SOAP message.


> 
> 
>>I honestly don't understand how you can claim that the semantics
>>of a SOAP Fault EII as child of the SOAP Body EII is somehow
>>a violation of R803. To restate R803:
>>
> 
> It would be a violation of R803 if the processing model said something
> like "if the envelope contains a fault, then do such-and-such".
> 
> This is because, in the chameleon view, the presence of a fault on the
> wire is insufficient information to know whether it is to be processed
> as a fault.  The outermost containing context for the fault, in this
> case the envelope of the application protocol, is authoritative, in
> roughly the same way that;
> 
> <not>
>   <banana/>
> </not>
> 
> means "not a banana", and you wouldn't want an intermediary that counts
> bananas to count that as a banana.


You've lost me entirely.


> 
> 
>>As I have pointed out, a SOAP intermediary doesn't "process"
>>in the SOAP sense the contents of the SOAP Body EII. An intermediary
>>that processes the SOAP message (in the SOAP sense) is by definition
>>a SOAP node and MUST abide by the SOAP processing rules as defined
>>in section 2.6 of SOAP 1.2 Part 1.
>>
> 
> But an HTTP intermediary doesn't "process" the SOAP message; it knows
> nothing of SOAP.  But it does know about success and failure.


Now I am completely at a loss to understand what your issue is.

The resolution to issue #12 says that if a fault is generated,
as a result of SOAP processing, you use a non 2xx HTTP status
like 5xx or 4xx. That seems consistent with the chameleon view
in my mind, so I'm at a loss to understand what issue you might
have with that aspect.

On the other hand, you say you have a use case where you want
the equivalent of GET /errors/404 HTTP/1.1 which returns a SOAP
message that is identical in all respects to a generated SOAP
Fault message, tack it onto an HTTP/1.1 200 OK response and
have it treated by the receiving SOAP node as <not><fault/></not>
(as well as by any non-SOAP intermediaries).

What I'm saying is that you cannot do this consistently for
*all* transport/transfer mechanisms because they are not all
as perfect as HTTP. SOAP is intended to be independent of
any underlying transport/transfer mechanism used to convey
SOAP messages:

     R600

     The XMLP specification must not mandate any dependency on specific
     features or mechanisms provided by a particular transport protocol
     beyond the basic requirement that the transport protocol must have
     the ability to deliver the XMLP envelope as a whole unit. This
     requirement does not preclude a mapping or binding to a transport
     protocol taking advantages of such features. It is intended to
     ensure that the basic XMLP specification will be transport neutral.
	
     R604

     The XMLP specification must consider the scenario where an XMLP
     message may be routed over possibly many different transport or
     application protocols as it moves between intermediaries on the
     message path. This requirement implies it must be possible to apply
     many transport or application protocol bindings to the XMLP message
     without information loss from the XMLP message content.

A SOAP message carries its own semantics. To a SOAP Processor, a
SOAP message with a SOAP Fault EII as the child EII of the SOAP Body
EII is a Fault, barring any SOAP Header extension that modifies these
semantics. If you want to convey the equivalent of carrying a 404
response entity body's HTML representation on an HTTP 200 OK, then
you need to have some equivalent in SOAP. The SOAP Header extension
example I gave in my previous posting would be an example of that.
There's just no escaping this IMO or else you've broken SOAP for
anyone not using HTTP protocol (exclusively) which defeats the
whole point of SOAP (IMO).

To impose a requirement that all underlying transport/transfer
mechanisms to which SOAP is bound be capable of (natively)
conveying fault information the way HTTP does/can is unrealistic
and violates R600 above.

> 
> 
>>Anything else is simply not
>>a SOAP intermediary, but that doesn't preclude a non SOAP intermediary
>>at the transport level (routers, switches, proxies, etc.)
>>
>>Additionally, in a side thread on this list[2], you are arguing
>>that HTTP is NOT a 'transport' and R803 is about 'transport'
>>intermediaries;) (couldn't resist that:)
>>
> 
> I knew this would come back to haunt me! 8-)
> 
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0022.html
> 
> MB
>

Received on Friday, 29 March 2002 11:31:42 UTC