https://bz.apache.org/bugzilla/show_bug.cgi?id=65448
Bug ID: 65448
Summary: Download of file via Servlet OutputStream blocks when
using SSL
Product: Tomcat 9
Version: 9.0.50
Hardware: PC
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ro...@auxilii.com
Target Milestone: -----
Created attachment 37950
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37950&action=edit
A ZIP file containing curl outputs, threaddumps and system information
We have a very simple Servlet implementation that lets clients download a file.
Here's the code:
try (InputStream in = new BufferedInputStream(new
FileInputStream(resourceFile), IOTools.SIZE_64K)) {
IOTools.pump(in, response.getOutputStream());
}
The pump method copies the bytes from the InputStream to the OutputStream (in
blocks of 64K) and flushes the OutputStream after that.
The problem:
When downloading a file with cURL command:
curl -v --insecure
"https://btdevapp01:8443/tribefire-services/res/adx/fonts/exactly130703.txt";
--output test.txt
it will block halfway through the response and will wait 1 min until the
download resumes and finishes successfully.
Here are some observations:
* When the downloaded file is below the size of 130.703 Bytes, the download
works all the time. Only when the file is greater or equal to 130.073 Bytes,
the download might fail.
* The 1 min waiting period is related to the configured "connectionTimeout" in
the server.xml. When we increase that config to - say - 120.000, we have to
wait 2 minutes until the download finishes.
* This problem only occurs when using HTTPS. When using the equivalent HTTP
address, it works all the time for all file sizes.
* This is not just a problem with cURL. We were able to reproduce problems with
Chrome 91 and Firefox 90.
* With the help of JMX, we can read out that the Maximum Request Time of the
HTTPS Connectors is 3487 ms. Hence, it does not register that the user has to
wait over a minute to get the full result.
We were not able to reproduce the problem on our local environments, but this
might also be because we're using mostly Macs and the target platform where we
encounter the problem is Windows Server 2019.
I am attaching the following:
* cURL output of downloading the same file twice, one time it is ok
(curl-working.txt) and one time when it fails (curl-failing.txt)
* Threaddumps of the server, one while it is idle (threaddump-idle.txt), one
when it is blocking (threaddump-blocking.txt) (where I cannot find anything
suspicious).
* Information about the server (Tomcat and Host) in server-info.txt
* A video showing how downloading the same file works 7 times, then fails, and
after that works again.... (edit: this exceeds the limit of the ticketing
system but can be provided on request)
I understand that this is very little to work with but this is all the
information that we could compile.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
