2013/2/18 Jesus Castillo <[email protected]>:
> This weekend I was doing some testing and I realized that some of them
> started failing for no reason.
> After a while, I was able to trace this to the changes in the
> ReadHeadersInterceptor
> and MustUndertstandInterceptor interceptors related to the fix:
>
> https://issues.apache.org/jira/browse/CXF-4819.
>
> However, I think the fix now is breaking SOAP spec since now if
> mustUnderstand attribute is set
> to "true" in a custom header but no Soap interceptor is handling the same,
> CXF is silently ignoring it
> instead of raising a Soap fault.
>
> As per SOAP spec (http://www.w3.org/TR/soap12-part0/#L1474):
>
> "A env:mustUnderstand value of "true" means that the SOAP node must process
> the header with the
> semantics described in that header's specification, or else generate a SOAP
> fault. "

That is probably true - the receipient should raise a fault if
mustUnderstand="1" and is not processed by the receiver.
However - I don't think true|false are allowed values, only 0|1.
See:
http://schemas.xmlsoap.org/soap/envelope/
"reverted mustUnderstand to only allow 0 and 1 as lexical values"

> Regarding my use case, the mustUndestand attribute is REQUIRED if the custom
> header is present
> and I was validating this. Now I have no way to know if the attribute was
> present or not as
> it's removed.
>
> I understand that the issue was reported because this attribute is in a
> different NS but that's how
> SOAP spec defines it. As I see it, there are two cases:

My problem was not due to the attribute being declared in the soap NS
(which it is - and is correct.)
My problem is that we declare an explicit soap header (see:
http://www.ibm.com/developerworks/library/ws-tip-headers/index.html)
which does NOT declare the mustUnderstand attribute (and it's optional
to do so).
However we have some axis2 clients that do add the header, and set it
mustUnderstand="0" - which they should probably be free to do - and
this fails the jaxb2 validation of that header, as the attribute is
not declared in our schema, and we're not obliged to do.

>
> 1. A Custom Interceptor NOT present and mustUnderstand is true. CXF should
> manage this and report
> a fault as per the spec.
>
> 2. Custom interceptor present. If the mustUnderstand is REQUIRED, then the
> interceptor should validate
> this (assuming that it still has access to the attribute which is not the
> case right now with the new fix).
> if OPTIONAL, nothing is done.
>
> BRgds.
>
> Jesus.

-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Reply via email to