[
https://issues.apache.org/jira/browse/CXF-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127846#comment-18127846
]
Freeman Yue Fang commented on CXF-8542:
---------------------------------------
This should be fixed by CXF-9057 (fixed in 3.5.11, 3.6.6, 4.0.7 and 4.1.1).
With CXF-9057, if the DataHandler's InputStream fails while the MTOM
attachments are being written, the response is aborted rather than completed
with truncated data:
* if the response is not committed yet, it is reset and closed, and the client
gets an exception from the invocation (e.g. {{Couldn't find MIME boundary}});
* if the response is already committed, the connection is aborted, and the
client gets an {{IOException}} while reading the attachment (e.g. {{Premature
EOF}}).
I reproduced the scenario from the description: the server's attachment stream
throws an {{IOException}} after 1 KB (response not yet committed) and after 1
MB (response committed), with both the HttpClient and the URLConnection
conduit. On current main, the client gets an error in all cases. With the
CXF-9057 changes reverted, it silently receives the truncated attachment.
I will send a PR that adds this as a regression test to demonstrate it.
> MTOM: Exceptions while reading the DataHandler's InputStream are not signaled
> to the client
> -------------------------------------------------------------------------------------------
>
> Key: CXF-8542
> URL: https://issues.apache.org/jira/browse/CXF-8542
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 3.4.3
> Reporter: Joern Gebhardt
> Assignee: Freeman Yue Fang
> Priority: Major
>
> If the DataHandler's InputStream throws an exception while transferring the
> data to the client, the client gets no clue that it has received incomplete
> data. Instead, the client believes that it has received the full data.
> I'd expect to get an exception while reading the {{InputStream}} from the
> {{DataHandler}}.
> Here's what happens on the server side:
> The IOException is caught in the {{AttachmentOutEndingInterceptor}} that
> transforms it into an {{Fault}} runtime exception:
> {code:java}
> Interceptor for
> {http://example.com}MyWebService#{http://example.com/ws}GetBinaryData has
> thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not write attachments.
> at
> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingInterceptor.handleMessage(AttachmentOutInterceptor.java:123)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> ...
> {code}
> This {{Fault}} is caught by the {{PhaseInterceptorChain}} which in turn
> returns {{false}} which is ignored by the {{ChainInitiationObserver}}. I.e.
> it seems to make no difference if the InputStream can be read correctly or if
> an exception is thrown while reading it.
> As I'm no CXF developer and cannot see the full picture I might be mistaken
> by my analysis. However, from the client's perspective the MTOM data seems to
> be correctly retrieved from the server which is not the case.
> Is there anything that can be done to make sure that the client receives an
> exception if the InputStream gets unexpectedly aborted on the server side?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
