[
https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320266#comment-15320266
]
Akitoshi Yoshida commented on CXF-6863:
---------------------------------------
Hi Dennis,
Ok. Right. That is a good point. Regarding the attachments
encryption/signature, we have the processed attachments and the merging itself
shouldn't corrupt the data, I think, because encryption/signing is done within
each attachment and not across multiple parts. The security processed
attachments themselves are reusable for retransmission because there is no
timestamp attached to them. However, the retransmission will currently re-apply
security processing to the attachments and that will be wrong. We we re-use the
processed attachments, we need to skip security processing for the attachments
at retransmission. Alternatively, we could store the original attachments when
ws-sec on attachments is configured and apply security processing at each
retransmission. In any case, we will need one of these two options to support
ws-rm + ws-security on attachments.
regards, aki
> WS-RM 3.x does not work with attachments upon a network error
> -------------------------------------------------------------
>
> Key: CXF-6863
> URL: https://issues.apache.org/jira/browse/CXF-6863
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 3.1.3, 3.0.9
> Reporter: Akitoshi Yoshida
> Assignee: Akitoshi Yoshida
> Attachments:
> 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch
>
>
> When sending messages with an attachment, the CXF 3.x WS-RM code may lose
> message at the client side when a network error occurs. This was working with
> CXF 2.x WS-RM.
> This problem is related to the change CXF-4866 which changed the way how the
> outgoing message is captured. Previously, the entire message was buffered and
> captured, which isolated this capturing from network issue. In 3.x, only the
> SOAP part is captured in this way and not the attachments. As a result, an
> exception will be thrown during the attachment serialization when a network
> error occurs and the message will not be correctly placed in the
> retransmission queue.
> By comparing CXF 3.x and 2.x code,
> In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and
> this can trigger a Fault from AttachmentOutInterceptor.handleMessage.
> URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[],
> int, int) line: 61
> URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[])
> line: 60
> CacheAndWriteOutputStream.write(byte[]) line: 89
> AttachmentSerializer.writeProlog() line: 182
> AttachmentOutInterceptor.handleMessage(Message) line: 77
> whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the
> buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts
> WriteOnCloseOutputStream to isolate itself from any network issue.
> WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466
> CacheAndWriteOutputStream.write(byte[]) line: 89
> AttachmentSerializer.writeProlog() line: 172
> AttachmentOutInterceptor.handleMessage(Message) line: 72
> CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to
> capture the message entirely.
> There seem to be other issues with attachments handling in CXF 3.x. Along
> with other issues CXF-6646, I am not sure how we should fix all these issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
