[
https://issues.apache.org/jira/browse/CXF-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18084114#comment-18084114
]
Freeman Yue Fang commented on CXF-9129:
---------------------------------------
I'm revisiting this issue and I found that the root cause is
WSS4JOutInterceptor eagerly consuming the attachment stream during the signing
phase when MTOM is enabled, which prevents streaming DataHandler
implementations from working correctly. WSS4J itself actually provides a way to
address this — setting expandXOPInclude=false and storeBytesInAttachment=false
— but CXF's translateProperties() fails to correctly propagate those
WSS4J-level settings to the message context, so even when a user explicitly
configures those flags, they are silently ignored by the rest of the CXF
pipeline. A fix and corresponding test coverage are being prepared.
> Chunked attachment streaming not working when using ws-security
> ---------------------------------------------------------------
>
> Key: CXF-9129
> URL: https://issues.apache.org/jira/browse/CXF-9129
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 4.1.1
> Environment: CXF Version: 4.1.1
> OS: Windows 11
> Java Version: openjdk 21.0.7 2025-04-15 LTS
> Container: Spring Boot 3.4.4 / Tomcat 10.1.39
> Reporter: Mike M.
> Assignee: Freeman Yue Fang
> Priority: Major
>
> We have a project that uses JAX-WS with ws-security. The policy is set to
> sign and encrypt all messages. Some operations involve long responses. These
> responses have a size of multiple megabytes and take some time to process on
> the server. We have the problem that some layer-7 firewalls or http proxies
> don't like to wait too long before receiving at least the response headers.
> They tend to cut the connection with a timeout-type error before the server
> is done processing the full response.
> To mitigate this, we are trying to do the following: The part of the response
> that takes long to process has already been encapsulated into an attachment
> like this:
> {code:xml}
> <xs:complexType name="ExampleOperationResponseType">
> <xs:sequence>
> <xs:element name="data" type="xs:base64Binary"
> xmime:expectedContentTypes="application/octet-stream" />
> </xs:sequence>
> </xs:complexType>
> {code}
> We are trying to use the DataHandler API provided by the JAXB binding to let
> the server stream the response attachment. The idea being that: if the server
> can return the main response-body immediately and return the attachment using
> a chunked Transfer-Encoding of MTOM attachments, this could prevent the TCP
> connection from sitting idle and prevent proxies from cutting it.
> When we try that without ws-security, it seems to work exactly like that.
> However, as soon as we add signing and/or encryption, the server behaves
> differently: It caches the whole response while writing the attachment. Only
> when it's fully done writing the attachment, it sends the response to the
> client in one go (despite having a "{{Transfer-Encoding: chunked}}" http
> header).
> In order to facilitate reproducing this, I created a standalone dummy project
> that contains a unit test showing the issue:
> https://github.com/netmikey/cxf-security-boot-test
> See the CxfAttachmentStreamingTest. The tests in this class send a request to
> the server. The server then returns a response that contains a binary
> attachment. The server is set up such that it takes some time to stream the
> attachment data. We expect chunked streaming to take place. That is: the
> client should obtain the response in chunks while the server is still
> streaming the attachment. That is checked by capturing the timestamps of when
> the client receives the initial response body and when the server finishes
> streaming. It is expected that the client starts receiving the response
> before the server finishes streaming.
> Am I wrong expecting attachment streaming to work when ws-security is in
> place? If so, why couldn't this work? If not, is this an issue that could be
> fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
