I'm not sure whether  I have enough  time to look into this issue
today but I will try within next few days with my time availability.
BTW if you have any test case or runnable sample to reproduce the
issue  please attach it along with the issue, such sample definitely
help us to understand your issue and also reduce the resolution time.

Thanks !

On Fri, Dec 28, 2012 at 5:17 PM, Brian Reinhold
<[email protected]> wrote:
> Dear Sagara Gunathunga ,
>
> I see you have been INCREDABLY busy today fixing and resolving bugs. If you 
> get a chance might you take a look at bug 5431? This bug concerns 
> WS-Addressing and the mustUnderstand attribute. The standard is not 100% 
> clear on the exact behavior but this is how I understand it.
>
> 1. The client sends out a request with some WS-Addressing header elements 
> containing the mustUnderstand attribute set to true (or 1)
> 2. The request (for success) shall contain the matching  header elements with 
> the mustUnderstand attribute set to true.
> 3. Not all WS-addressing headers need to contain the mustUnderstand attribute
>
> The behavior I get is that the response contains no mustUnderstand attributes 
> at all. Looking at the code I put in something which I believe is correct but 
> I am not 100% sure. In the addressing module I check the incoming message for 
> the mustUnderstand attribute and set a parameter that the kernel later uses 
> to set these attributes in the response. I notice here that the 
> mustUnderstand attribute is treated globably; if one header is has the 
> attribute, all headers are assumed to have the attribute. At least this 
> approach gives me the mustUnderstand attribute in the response.
>
> Thanks,
>
> Brian Reinhold
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>



-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to