We have an application that uses a java script file of size around 700Kb that will be downloaded as part of the client. The connector used was NIO . All these days we did not see any issue till Tomcat 7.0.26. When we upgraded it to the latest Tomcat version 7.0.27 we started getting this problem. The file is never getting downloaded the connection will be broken in middle. And we used fiddler to see what is happening and it gives us a message as below “Content-Length mismatch: Response Header indicated 757,692 bytes, but server sent 262,142 bytes.” If I use the default connector there is no issues. it works fine. To reproduce this we have created a sample application. Please follow the steps below. Clean up all the browser cash: 1. Deploy TestNIOConnector app in tomcat. 2. In server.xml change to connect to NIO as shown below. <Connector port="9880" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" connectionTimeout="70000" acceptCount="100" compression="on" acceptorThreadCount="2" redirectPort="8443" /> 3. Start the service and try to access this file using the following URL in IE. http://localhost:9880/TestNIOConnector/apidocs.js
Created attachment 28666 [details] Sample app to reproduce this issue This app is to reproduce the issue.
I am having the same problem with my application. We have noticed only some files are not downloading, not all of them - there's no apparent pattern to the file size. We had one file that's 115397 download, but another that's 111158 fail. What made it interesting was that the file did not download in IE 8, but the file did download in FF 12. This leads me to believe it's something browser specific about downloading the file. My searches led me to an item for 7.0.27, https://issues.apache.org/bugzilla/show_bug.cgi?id=52858 that looked interesting. Perhaps the issue relates to that change.
Just ran the sample app on a 7.0.27 download HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"757692-1335976856000" Last-Modified: Wed, 02 May 2012 16:40:56 GMT Content-Type: application/javascript Content-Length: 757692 Date: Wed, 02 May 2012 16:43:11 GMT and then I get all the bytes. <Connector port="9880" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" connectionTimeout="70000" acceptCount="100" compression="on" acceptorThreadCount="2" redirectPort="8443"/> I was unable to reproduce it. The last bytes I get downloaded are: Y.on('hashchange', function (e) { pjax.updateTabState('hashchange'); }, win); }); and that corresponds with the file contents
Tested in Firefox 11 and Internet Explorer 9
(In reply to comment #4) > Tested in > Firefox 11 and Internet Explorer 9 Tomcat installation: <Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="xxx/.keystore" keystorePass="xxx" keyPass="xxx"/> Running on HPUX 11.11: 64 bit JVM java version "1.6.0.14" Java(TM) SE Runtime Environment (build 1.6.0.14-jinteg_07_mar_2012_00_45-b00) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-jre1.6.0.14-rc1b2 PA2.0W (aCC_AP), mixed mode) ------- On Windows XP, Using IE 8, I get 114,688 bytes of the file. It takes a long time to download the file after the first chunk of data. I'm guessing it just gives up and stops. Using FF 12, I get about the same size of data initially - the file's progress is paused - I get the "Connecting" status - but after a while, the document completes and I get the whole size.
Thanks Robert, are you able to reproduce this on a non HPUX system with a more recent runtime? ie, can you reproduce the attached test case on your local laptop or workstation?
(In reply to comment #6) > Thanks Robert, are you able to reproduce this on a non HPUX system with a > more recent runtime? ie, can you reproduce the attached test case on your > local laptop or workstation? Yes. I just finished testing this on my PC: Windows XP SP 3 32 bit JVM java version "1.7.0_03" Java(TM) SE Runtime Environment (build 1.7.0_03-b05) Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode, sharing) It worked on Tomcat 7.0.26. I installed 7.0.27, and it didn't work. I went back to 7.0.26, and it works again.
Thanks Robert, I can reproduce it with IE 9 if I hit the "Save" option when I hit refresh in the browser. I will check on this and see how it works out
In the meantime a workaround for this is to set useSendfile="false" <Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="xxx/.keystore" keystorePass="xxx" keyPass="xxx" useSendfile="false"/>
Current suspect is: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?r1=1300872&r2=1300950&diff_format=h
(In reply to comment #10) > Current suspect is: > http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/ > util/net/NioEndpoint.java?r1=1300872&r2=1300950&diff_format=h Confirmed that the above check in broke sendFile for NIO. Current workaround is useSendfile="false" on the NIO connector
Fixed in trunk in r1340215 Fixed in 7.0.x in r1340218 Will be available in 7.0.28
*** Bug 53331 has been marked as a duplicate of this bug. ***
This same issue is still happening on Tomcat 8. Setting the flag useSendData to false is a workaround my team has applied for now, but the bug is till there in Tomcat 8 and we would like to avoid using useSendData=false because increased CPU consumption. This issue is happening using with apache-tomcat-8.0.18 in Windows 7 environment
This specific issue was fixed for 8.0.x almost 5 years ago. If you are seeing an issue with similar symptoms, please test with the latest 8.0.x release (8.0.43 as I type this) and if you still see the issue please create a new bug report. You'll need to provide the simplest set of steps to reproduce the issue on a clean install of the latest 8.0.x release.
Revert bug description. It's still insanely long, but there is no need to thrash web indexers on this old issue.
It is an old issue but it still happening it seems. We get this error in Chrome Electron 51, but not with other browsers. My guess is that the error is being ignored by other browsers. We haven't validated yet with 8.0.43, but we see it with 8.0.18. I will open a new bug after I validate with 8.0.43 in case it still happens with this version.