[
https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512910
]
Ulhas Bhole commented on CXF-790:
---------------------------------
Hi Fred,
What you are mentioning
"I would prefer instead that the SOAPMessage representing the response, as it
is passed to the outbound interceptor on the server side, be more of a blank
slate. "
was the original behavior but we try to do it now and it will break out-of-band
headers and any application specific headers that were added from service side
will be removed even before reaching the other side.
Every component/module which adds the headers to SOAPMessage should also have a
capability to consume it and remove it from the HeaderList while reading. This
was never enforced or affected the applications until the Headers were changed
from DOM elements to List and made available to application via.
WebServiceContext for application specific out-of-band header. Latter part (of
making header list available to application and sending the out-of-band headers
back) made this problem visible.
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to
> be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the
> response has to use the header information to "decode" the message, since the
> security headers contain implicit instructtions for decrypting and verifying
> signatures on elements in the message (possibly elements in the security
> header, itself). Typically, the originator of the request (e.g., the client)
> does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the
> SAAJ SOAPMessage of its headers as part of its processing the request, but i)
> it's not clear we really want to do that -- subsequent consumers on the
> interceptor chain, or possibly the application itself, may need this
> information; ii) furthermore, there's no guarantee that a security
> interceptor will be installed in an application, so there are scenarios where
> such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it
> is passed to the outbound interceptor on the server side, be more of a blank
> slate.
> This probably applies to other WS-* specs that rely on proper processing of
> SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
