[
https://issues.apache.org/jira/browse/CXF-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985438#action_12985438
]
Dennis Sosnoski commented on CXF-352:
-------------------------------------
This is an old issue, and in the interim some aspects of WS-RM have been
clarified. WS-RM must *not* change the WS-A MessageID in resent messages (see
http://www.ws-i.org/Profiles/ReliableSecureProfile-1.0-2010-11-09.html#retransmission),
since it is the same message being resent. But it needs to replace the
SequenceAcknowledgement if present, and also must run the message through
security processing again (if applicable). Resending a secured message with the
same Timestamp is totally broken behavior.
So the existing retransmission behavior works only for unsecured messages, and
only for WS-RM implementations which are tolerant of bad
SequenceAcknowledgement values.
> Update WS-A MessageID and WS-RM Acknowledgement headers in resent messages
> ---------------------------------------------------------------------------
>
> Key: CXF-352
> URL: https://issues.apache.org/jira/browse/CXF-352
> Project: CXF
> Issue Type: Task
> Components: WS-* Components
> Reporter: Andrea Smyth
>
> Currently a message is resent as is. This implies use of the originally
> assigned messageID, and works because we are by default tolerant against
> duplicate messageIDs . To be strictly compliant, the resent message should
> be given a new ID. Once we are updating the headers, we may also either
> remove any pre-existing SequenceAcknowledgement header (it may be
> out-of-date, but that does not cause any harm) or, for efficiency, replace
> it with an up-to-date SequenceAcknowledgement.
> Requires re-running the message through a selective chain of interceptors or
> else a manual approach to updating the headers in question. and subsequently
> re-marshalling the messge.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
