2013/2/18 David Karlsen <[email protected]>: > 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).
I think the correct way is to include the any-attribute decl <xs:anyAttribute namespace="##other"/> in any header element types. So, I am confused when you says "it's optional". Is the declaration optional or the attribute itself is optional? I thought the declaration is mandatory if the attribute appears. And you can look at the standard schemas for various WS specs like. ws-security, ws-rm, etc which all have the any-attribute declared for their header elements. The soap-ns attributes may not be the only one you want to optionally add out-of-the-band to the header instaces. You may want to add wsu:Id etc to do signing/encrypting. So, I think CXF may introduce an option to ignore certain attributes if that would help it to interoperate with those systems that do not follow this rule. But which ones? All global attributes or only SOAP or with WSU? Do you know if Axis2 is validating the message when it sends the message with that header with the mustUnderstand="1"? regards, aki > 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
