The latter sounds reasonable to make clients aware of violation of
protocol, but probably as a configurable option ("strict" mode?). Spec does
not tell how server should behave in these cases?
14. jan. 2014 00:21 skrev "Daniel Kulp" <[email protected]> følgende:> > On Jan 13, 2014, at 2:52 PM, Jose María Zaragoza <[email protected]> > wrote: > > > 2014/1/13 Daniel Kulp <[email protected]>: > >> > >> These are showing that the RelatesTo header wasn’t there or similar as > it couldn’t correlate the response message to a request. That is > certainly the cause of the “leak” as the WS-Addressing stuff is not seeing > a proper response to the request. > >> > > > > Thanks Daniel for you reply > > > > In any case, if I don't use WS-Addressing , responses are correlated > > to a request , even the JAX-WS proxy client is shared by many threads. > > I don't know how Apache CXF do it but, would be possible to follow the > > same correlation rule if RelatesTo header is not present in responses > > ? > > Digging through the code, there certainly doesn’t look like an easy way. > You’d likely need to write an interceptor that would grab the headers from > the message, loop through, and if there isn’t a RelatesTo header, it either > adds one or deletes all the addressing headers. > > > I would like to protect my webservice against malformed remote responses > > Well, there is the question of what SHOULD CXF be doing with this. An > argument certainly could be made that CXF should be throwing an exception > at this point for a malformed Addressing message. However, if that > occurred, the response wouldn’t be processed at all and the client would > get the exception. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > >
