You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jesus Castillo <je...@gmail.com> on 2013/02/18 04:48:33 UTC
CXF-4819 breaking validation of mustUnderstand attribute
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. "
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:
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.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Daniel Kulp <dk...@apache.org>.
On Feb 20, 2013, at 12:10 PM, Jesus Castillo <je...@gmail.com> wrote:
> I'm using 2.7.x branch.
>
> Today's build is working fine though.
>
> I tested and all my tests passed.
> I also tested the more general case when a custom header with mustUnderstand
> attribute equals true
> is received and no handler is present and it is working fine too since a
> Soap fault is thrown as expected.
>
> Thanks.
>
> P.S. Is this a permanent solution?
I think so. Unit test added so hopefully it won't break again. :-)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Jesus Castillo <je...@gmail.com>.
I'm using 2.7.x branch.
Today's build is working fine though.
I tested and all my tests passed.
I also tested the more general case when a custom header with mustUnderstand
attribute equals true
is received and no handler is present and it is working fine too since a
Soap fault is thrown as expected.
Thanks.
P.S. Is this a permanent solution?
Jesus.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723508.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Daniel Kulp <dk...@apache.org>.
On Feb 20, 2013, at 10:50 AM, Jesus Castillo <je...@gmail.com> wrote:
> Hi Dan,
>
> I tested but I'm not able to see those changes in the jar.
> Were they part of the last build?
On which branch? 2.7.x?
It looks like the trunk (2.8.x) branch failed to deploy for some reason:
https://builds.apache.org/view/A-F/view/CXF/
but the 2.7.x build did succeed. I'll look into the trunk builds.
Dan
> I'm still seeing the old code that remove the attribute in the
> ReadHeadersInterceptor.
>
> Rgds,
>
> Jesus.
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723491.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Jesus Castillo <je...@gmail.com>.
Hi Dan,
I tested but I'm not able to see those changes in the jar.
Were they part of the last build?
I'm still seeing the old code that remove the attribute in the
ReadHeadersInterceptor.
Rgds,
Jesus.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723491.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Aki Yoshida <el...@gmail.com>.
2013/2/20 Daniel Kulp <dk...@apache.org>:
>
> On Feb 20, 2013, at 5:30 AM, Aki Yoshida <el...@gmail.com> wrote:
>
>> I still don't think it's a good idea to interfere with the validation
>> in that way by default. As I commented here earlier, the corresponding
>> schema should include the any-attribute declaration if the header is
>> to be schema-validated. I think this implicit handling may lead to
>> confusion when other tools may strictly invalidate those headers.
>>
>> Furthermore, there seems to be another aspect. Today, I digged a
>> little bit and found that there is a use case to catch this error:
>> http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html#annotation
>>
>> here, the mustUnderstand header is declared to be prohibited in the
>> Claim header.
>>
>> But as I said, we could offer an option to introduce an option to
>> ignore soap attributes or maybe all global attributes to cover for wsu
>> attributes as well.
>>
>> How do you think?
>
> I definitely have a different view point. With all the customers and use cases I've dealt with, the Schema elements represent the domain model for the application. In many cases, that model isn't even under the control of the people writing the front end services. It completely represents the model of the data that is part of their application. How that data gets passed back and forth is not part of the concern of the people writing the model.
>
> The soap attributes are a transport specific thing. It's something that only applies when transferring that data over soap. It should not have any affect on the appearance of the objects within the application domain.
>
> The soap spec specifically allows adding attributes onto these elements. Thus, the soap layer needs to handle the cases where the transport layers start polluting the data with extra information that is not applicable to the domain model. For this specific case, it include the mustUnderstand and actor/role things. However, it can also be the wsu:Id attribute and others.
>
> As an example, if I have an existing application up and running using normal basic auth or similar. However, we now want to add ws-security stuff to sign the headers. That's an administrator/security domain thing and that shouldn't impact the application level objects and schema. They shouldn't have to go back and add attributes onto the various objects to get the validation that was working fine to work again.
>
> Anyway, for the most part, most people that I've encountered do not want the soap spec stuff to pollute their domain models. However, we also need to be able to accept requests that have that mustUnderstand attribute on them as the soap spec requires that. Thus, I think the current behavior is closer to "correct". One thought is that we could look at the schema (we have it in the XmlSchemaCollection stuff) to see if the root element has some extensibility or restriction capabilities on it for the attributes and use a scaled down error handler in those cases. Just a bit more work to do.
>
Hi Dan,
I think we actually have the same view. I absolutely agree with you
that the domain model should not be concerned with some external
extensions like soap, ws, etc or any future unknown out-of-the-band
extensions. And that is the reason why the schema spec provided
<xs:anyAttribute namespace="##other"/> that allows you to use those
external extensions with your domain model without your domain model
needing to know of those extensions. Many standard schemas as well as
CXF's own config schemas are utilizing the anyAttribute wildcards in
this way.
Unfortunately, there is a shortcoming with this any-attribute
mechanism. Namely, some existing schemas may not have it. In addition,
it is cumbersome to include the any-attribute everywhere where you
want to expect external extensions.
To overcome this shortcoming, CXF can offer an option to assume at the
validation that every element has implicitly <xs:anyAttribute
namespace="##other"/> declaration. If the original schema has some
"forbid" or "required" global attribute declarations, we should honor
these rules. But when we find a global attribute which is not declared
in the schema, we can accept it even if the schema does not include
the any-attribute declaration. This behavior is not specific to soap.
So if CXF is to support wsu:Id or some other existing or future
external extensions while using the schema which does not include the
any-attribute decls, we can handle these attributes as well
automatically. We can decide if this behavior is by default or
optional. In this way, we can have a generic and flexible validation
mechanism to support both strict and generous validation. I think this
idea is not contradicting to your view.
By the way, while thinking on this, I wished that XMLSchema included a
schema-level option to say <anyAttribute> is included everwhere. So
you can write something like
<schema
targetNamespace="http://cxf.apache.org/hello_world_soap_http/types"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
anyAttributeDefault="##other">
If this was there, people might have used it and we wouldn't have run
into this issue.
But this is another topic.
regards, aki
>
> Dan
>
>
>>
>> aki
>>
>> 2013/2/19 Daniel Kulp <dk...@apache.org>:
>>>
>>> I just made some more changes to this that will hopefully work a bit better.
>>>
>>> Basically, rather than remove the attributes from the Element, I stick an error handler onto the Schema validator to ignore the errors related to the mustUnderstand and Actor/Role attributes that SOAP clients may stick on the headers. Thus, if your schema does have them, JAXB should then be able to read them and populate the values but they won't generate validation errors if they are there.
>>>
>>> Can you give that a try to see if that then works for your use case?
>>>
>>> Dan
>>>
>>>
>>>
>>> On Feb 18, 2013, at 10:12 AM, Jesus Castillo <je...@gmail.com> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> For now, I disabled the validation of the attribute as a workaround until a
>>>> final solution is found.
>>>>
>>>> However, as this attribute is part of the schema defining the custom header,
>>>> I expect to retrieve it
>>>> too. In a perfect world, you shouldn't remove this attribute at all as this
>>>> is or should be part of the
>>>> custom schema if needed. So, if you are to remove it, I think this solution
>>>> should be the exception
>>>> and not the rule.
>>>>
>>>> Rgds,
>>>>
>>>> Jesus.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Daniel Kulp <dk...@apache.org>.
On Feb 20, 2013, at 5:30 AM, Aki Yoshida <el...@gmail.com> wrote:
> I still don't think it's a good idea to interfere with the validation
> in that way by default. As I commented here earlier, the corresponding
> schema should include the any-attribute declaration if the header is
> to be schema-validated. I think this implicit handling may lead to
> confusion when other tools may strictly invalidate those headers.
>
> Furthermore, there seems to be another aspect. Today, I digged a
> little bit and found that there is a use case to catch this error:
> http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html#annotation
>
> here, the mustUnderstand header is declared to be prohibited in the
> Claim header.
>
> But as I said, we could offer an option to introduce an option to
> ignore soap attributes or maybe all global attributes to cover for wsu
> attributes as well.
>
> How do you think?
I definitely have a different view point. With all the customers and use cases I've dealt with, the Schema elements represent the domain model for the application. In many cases, that model isn't even under the control of the people writing the front end services. It completely represents the model of the data that is part of their application. How that data gets passed back and forth is not part of the concern of the people writing the model.
The soap attributes are a transport specific thing. It's something that only applies when transferring that data over soap. It should not have any affect on the appearance of the objects within the application domain.
The soap spec specifically allows adding attributes onto these elements. Thus, the soap layer needs to handle the cases where the transport layers start polluting the data with extra information that is not applicable to the domain model. For this specific case, it include the mustUnderstand and actor/role things. However, it can also be the wsu:Id attribute and others.
As an example, if I have an existing application up and running using normal basic auth or similar. However, we now want to add ws-security stuff to sign the headers. That's an administrator/security domain thing and that shouldn't impact the application level objects and schema. They shouldn't have to go back and add attributes onto the various objects to get the validation that was working fine to work again.
Anyway, for the most part, most people that I've encountered do not want the soap spec stuff to pollute their domain models. However, we also need to be able to accept requests that have that mustUnderstand attribute on them as the soap spec requires that. Thus, I think the current behavior is closer to "correct". One thought is that we could look at the schema (we have it in the XmlSchemaCollection stuff) to see if the root element has some extensibility or restriction capabilities on it for the attributes and use a scaled down error handler in those cases. Just a bit more work to do.
Dan
>
> aki
>
> 2013/2/19 Daniel Kulp <dk...@apache.org>:
>>
>> I just made some more changes to this that will hopefully work a bit better.
>>
>> Basically, rather than remove the attributes from the Element, I stick an error handler onto the Schema validator to ignore the errors related to the mustUnderstand and Actor/Role attributes that SOAP clients may stick on the headers. Thus, if your schema does have them, JAXB should then be able to read them and populate the values but they won't generate validation errors if they are there.
>>
>> Can you give that a try to see if that then works for your use case?
>>
>> Dan
>>
>>
>>
>> On Feb 18, 2013, at 10:12 AM, Jesus Castillo <je...@gmail.com> wrote:
>>
>>> Hi Dan,
>>>
>>> For now, I disabled the validation of the attribute as a workaround until a
>>> final solution is found.
>>>
>>> However, as this attribute is part of the schema defining the custom header,
>>> I expect to retrieve it
>>> too. In a perfect world, you shouldn't remove this attribute at all as this
>>> is or should be part of the
>>> custom schema if needed. So, if you are to remove it, I think this solution
>>> should be the exception
>>> and not the rule.
>>>
>>> Rgds,
>>>
>>> Jesus.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Aki Yoshida <el...@gmail.com>.
Hi Dan,
I still don't think it's a good idea to interfere with the validation
in that way by default. As I commented here earlier, the corresponding
schema should include the any-attribute declaration if the header is
to be schema-validated. I think this implicit handling may lead to
confusion when other tools may strictly invalidate those headers.
Furthermore, there seems to be another aspect. Today, I digged a
little bit and found that there is a use case to catch this error:
http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html#annotation
here, the mustUnderstand header is declared to be prohibited in the
Claim header.
But as I said, we could offer an option to introduce an option to
ignore soap attributes or maybe all global attributes to cover for wsu
attributes as well.
How do you think?
aki
2013/2/19 Daniel Kulp <dk...@apache.org>:
>
> I just made some more changes to this that will hopefully work a bit better.
>
> Basically, rather than remove the attributes from the Element, I stick an error handler onto the Schema validator to ignore the errors related to the mustUnderstand and Actor/Role attributes that SOAP clients may stick on the headers. Thus, if your schema does have them, JAXB should then be able to read them and populate the values but they won't generate validation errors if they are there.
>
> Can you give that a try to see if that then works for your use case?
>
> Dan
>
>
>
> On Feb 18, 2013, at 10:12 AM, Jesus Castillo <je...@gmail.com> wrote:
>
>> Hi Dan,
>>
>> For now, I disabled the validation of the attribute as a workaround until a
>> final solution is found.
>>
>> However, as this attribute is part of the schema defining the custom header,
>> I expect to retrieve it
>> too. In a perfect world, you shouldn't remove this attribute at all as this
>> is or should be part of the
>> custom schema if needed. So, if you are to remove it, I think this solution
>> should be the exception
>> and not the rule.
>>
>> Rgds,
>>
>> Jesus.
>>
>>
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by David Karlsen <da...@gmail.com>.
My collegue tested it and it worked Wellington. No longer failing on
validation when mustUnderstand is 0.
Den 19. feb. 2013 21:43 skrev "Daniel Kulp" <dk...@apache.org> følgende:
>
> I just made some more changes to this that will hopefully work a bit
> better.
>
> Basically, rather than remove the attributes from the Element, I stick an
> error handler onto the Schema validator to ignore the errors related to the
> mustUnderstand and Actor/Role attributes that SOAP clients may stick on the
> headers. Thus, if your schema does have them, JAXB should then be able to
> read them and populate the values but they won't generate validation errors
> if they are there.
>
> Can you give that a try to see if that then works for your use case?
>
> Dan
>
>
>
> On Feb 18, 2013, at 10:12 AM, Jesus Castillo <je...@gmail.com>
> wrote:
>
> > Hi Dan,
> >
> > For now, I disabled the validation of the attribute as a workaround
> until a
> > final solution is found.
> >
> > However, as this attribute is part of the schema defining the custom
> header,
> > I expect to retrieve it
> > too. In a perfect world, you shouldn't remove this attribute at all as
> this
> > is or should be part of the
> > custom schema if needed. So, if you are to remove it, I think this
> solution
> > should be the exception
> > and not the rule.
> >
> > Rgds,
> >
> > Jesus.
> >
> >
> >
> > --
> > View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Daniel Kulp <dk...@apache.org>.
I just made some more changes to this that will hopefully work a bit better.
Basically, rather than remove the attributes from the Element, I stick an error handler onto the Schema validator to ignore the errors related to the mustUnderstand and Actor/Role attributes that SOAP clients may stick on the headers. Thus, if your schema does have them, JAXB should then be able to read them and populate the values but they won't generate validation errors if they are there.
Can you give that a try to see if that then works for your use case?
Dan
On Feb 18, 2013, at 10:12 AM, Jesus Castillo <je...@gmail.com> wrote:
> Hi Dan,
>
> For now, I disabled the validation of the attribute as a workaround until a
> final solution is found.
>
> However, as this attribute is part of the schema defining the custom header,
> I expect to retrieve it
> too. In a perfect world, you shouldn't remove this attribute at all as this
> is or should be part of the
> custom schema if needed. So, if you are to remove it, I think this solution
> should be the exception
> and not the rule.
>
> Rgds,
>
> Jesus.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Jesus Castillo <je...@gmail.com>.
Hi Dan,
For now, I disabled the validation of the attribute as a workaround until a
final solution is found.
However, as this attribute is part of the schema defining the custom header,
I expect to retrieve it
too. In a perfect world, you shouldn't remove this attribute at all as this
is or should be part of the
custom schema if needed. So, if you are to remove it, I think this solution
should be the exception
and not the rule.
Rgds,
Jesus.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723304.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Daniel Kulp <dk...@apache.org>.
If you grab the list of headers out of the SoapMessage, they should be SoapHeader objects which would shave the mustUnderstand and Actor attributes on them.
That said, I need to think about this a bit more. I THINK the jaxws handler TCK tests might be broken now for the same reason. I'll need to check. Probably need to remove those attributes much later in the chain instead of at initial header reading time.
Dan
On Feb 17, 2013, at 10:48 PM, Jesus Castillo <je...@gmail.com> wrote:
> 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. "
>
> 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:
>
> 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.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Aki Yoshida <el...@gmail.com>.
2013/2/18 David Karlsen <da...@gmail.com>:
> 2013/2/18 Jesus Castillo <je...@gmail.com>:
>> 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
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by Jesus Castillo <je...@gmail.com>.
Hi David,
Values 0|1 are for Soap 1.1. I'm using Soap 1.2.
Regarding your problem, it looks to me more like an issue with the
WSDL/Schema.
If your clients are sending this attribute, your app must declare it and be
prepared
for that. Take a look at this example
https://gist.github.com/dulanov/1010216
with WSDL and mustUnderstand declared OPTIONAL in the header.
In short, the attribute may be OPTIONAL but the declaration is mandatory if
you want
to handle it properly.
Rgds,
Jesus.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-4819-breaking-validation-of-mustUnderstand-attribute-tp5723289p5723303.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF-4819 breaking validation of mustUnderstand attribute
Posted by David Karlsen <da...@gmail.com>.
2013/2/18 Jesus Castillo <je...@gmail.com>:
> 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