[
https://issues.apache.org/jira/browse/CXF-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013260#comment-18013260
]
Freeman Yue Fang commented on CXF-9129:
---------------------------------------
Hi [~netmikey],
To enable streaming process for CXF and ws-security(WSS4J), you need explicitly
specify cxf endpoint property "ws-security.enable.streaming" as "true", so it
can become Stax based(while by default is't SAAJ/DOM based)
something like
{code}
--- a/src/main/java/com/example/cxf_security_boot_test/CxfConfiguration.java
+++ b/src/main/java/com/example/cxf_security_boot_test/CxfConfiguration.java
@@ -37,6 +37,7 @@ public class CxfConfiguration {
encryptProps.put(Merlin.PREFIX + Merlin.KEYSTORE_PASSWORD, "test");
encryptProps.put(Merlin.PREFIX + Merlin.KEYSTORE_FILE, "test.p12");
encryptProps.put(Merlin.PREFIX + Merlin.KEYSTORE_ALIAS, "test");
+ endpoint.getProperties().put("ws-security.enable.streaming", "true");
endpoint.getProperties().put(SecurityConstants.ENCRYPT_PROPERTIES,
encryptProps);
endpoint.getProperties().put(SecurityConstants.SIGNATURE_PROPERTIES,
encryptProps);
endpoint.getProperties().put(SecurityConstants.CALLBACK_HANDLER,
{code}
Best Regards
Freeman
> 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.
> 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)
