[
https://issues.apache.org/jira/browse/CXF-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015343#comment-18015343
]
Mike M. commented on CXF-9129:
------------------------------
Hi [~ffang],
Thank you for pointing out the property required to switch to Stax.
However, when I add the line as you suggest, the server responds with the
following for {{testStreamAttachmentEncrypt}}:
{code}
HTTP/1.1 500
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:723a076b-752a-48f1-8568-40895413f290";
start="<[email protected]>"; start-info="text/xml"
Content-Length: 841
Date: Thu, 21 Aug 2025 07:28:58 GMT
Connection: close
--uuid:723a076b-752a-48f1-8568-40895413f290
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>These
policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AlgorithmSuite</faultstring></soap:Fault></soap:Body></soap:Envelope>
--uuid:723a076b-752a-48f1-8568-40895413f290--
{code}
... and for {{testStreamAttachmentSignAndEncrypt}}:
{code}
HTTP/1.1 500
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:a94cfe13-4c5e-40d5-9785-bfd84adacc83";
start="<[email protected]>"; start-info="text/xml"
Content-Length: 1051
Date: Thu, 21 Aug 2025 07:28:58 GMT
Connection: close
--uuid:a94cfe13-4c5e-40d5-9785-bfd84adacc83
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>These
policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AlgorithmSuite
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Wss10
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts</faultstring></soap:Fault></soap:Body></soap:Envelope>
--uuid:a94cfe13-4c5e-40d5-9785-bfd84adacc83--
{code}
Am I missing something else?
> 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)
