Re: Issue with static file in Tomcat 8.5.17
On 21/07/17 13:08, Mark Thomas wrote: > On 21/07/17 08:13, Felix Schumacher wrote: >> Am 20.07.2017 22:33, schrieb George Stanchev: > The problem is related to the new code that handles the case when a > file is stored in one encoding but served in another. Since changing > encodings can change the value and number of bytes served (for example > serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). > This code did not handle requests that use accept-ranges correctly. >>> While the above is true, the actual problem looking more closely is that the content length can change when conversion is used. >>> Mark >>> >>> >>> Hi Mark, >>> >>> I hate to do this, but the issue is still around in another form. >>> After upgrading to the TC 8.5.18 which is currently under vote, Chrome >>> fails to parse the jquery file with "SyntaxError: Unexpected Token ?" >>> error. The response contains some data prior to the jQuery payload (it >>> is probably encoding stuff) that throws Chrome off. >>> >>> Unfortunately I cannot pinpoint exactly what is going on. >>> >>> The original jQuery - the one I sent you with the testapp trying to >>> reproduce the problem starts with "EF BB BF" before the actual >> >> The EF BB BF is called a Byte Order Mark (BOM) and is a marker to >> identify utf-8 >> coded files. A normal editor won't show those bytes. > > Yep. The BOM is the problem. When the UTF-8 file is written out as > ISO-8859-1, the BOM character is not mappable so it gets converted to > '?'. Generally that is what you want so you know something has gone > wrong. But not in this case. > > I'm looking at options for handling the BOM now. This is fixed for 8.5.x in revision 1802782 The patch also fixes a couple of related edge cases that were discovered. Feedback on this patch appreciated. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with static file in Tomcat 8.5.17
On 21/07/17 08:13, Felix Schumacher wrote: > Am 20.07.2017 22:33, schrieb George Stanchev: The problem is related to the new code that handles the case when a file is stored in one encoding but served in another. Since changing encodings can change the value and number of bytes served (for example serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). This code did not handle requests that use accept-ranges correctly. >> >>> While the above is true, the actual problem looking more closely is >>> that the content length can change when conversion is used. >> >>> Mark >> >> >> Hi Mark, >> >> I hate to do this, but the issue is still around in another form. >> After upgrading to the TC 8.5.18 which is currently under vote, Chrome >> fails to parse the jquery file with "SyntaxError: Unexpected Token ?" >> error. The response contains some data prior to the jQuery payload (it >> is probably encoding stuff) that throws Chrome off. >> >> Unfortunately I cannot pinpoint exactly what is going on. >> >> The original jQuery - the one I sent you with the testapp trying to >> reproduce the problem starts with "EF BB BF" before the actual > > The EF BB BF is called a Byte Order Mark (BOM) and is a marker to > identify utf-8 > coded files. A normal editor won't show those bytes. Yep. The BOM is the problem. When the UTF-8 file is written out as ISO-8859-1, the BOM character is not mappable so it gets converted to '?'. Generally that is what you want so you know something has gone wrong. But not in this case. I'm looking at options for handling the BOM now. Mark >> payload. When I run it through wget, the file on disk starts with just >> "3F". The response in Chrome looks like this: "0x62, 0x36, 0x65, 0x33, >> 0x0D, 0x0A, 0x3F" - so there is extra "b6e3\r\n" leading prior to the > > This looks like the length value that is needed for the chunked transfer. > It is not part of the request content. > > Do you have set the fileEncoding property? > > Felix > >> "3F". Below [1] is the request/response headers of the Chrome request. >> I've got also a HAR if this helps and I can send it to you email >> address as it will probably get stripped on the user-mailing list >> >> >> >> George >> >> >> Request Headers: >> GET http://hostname:8085/idp/javascript/jquery-1.8.3.min.js HTTP/1.1 >> Pragma: no-cache >> DNT: 1 >> Accept-Encoding: gzip, deflate >> Host: hostname:8085 >> Accept-Language: en-US,en;q=0.8,bg;q=0.6,und;q=0.4 >> User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 >> Safari/537.36 >> Accept: */* >> Cookie: JSESSIONID=blahblah >> Connection: keep-alive >> Cache-Control: no-cache >> >> >> Response headers: >> >> HTTP/1.1 200 >> Date: Thu, 20 Jul 2017 19:59:05 GMT >> X-Content-Type-Options: nosniff >> Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT >> ETag: W/"93640-1496825994000" >> X-Frame-Options: DENY >> Content-Type: application/javascript >> Transfer-Encoding: chunked >> Accept-Ranges: bytes >> X-XSS-Protection: 1; mode=block >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with static file in Tomcat 8.5.17
Am 20.07.2017 22:33, schrieb George Stanchev: The problem is related to the new code that handles the case when a file is stored in one encoding but served in another. Since changing encodings can change the value and number of bytes served (for example serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). This code did not handle requests that use accept-ranges correctly. While the above is true, the actual problem looking more closely is that the content length can change when conversion is used. Mark Hi Mark, I hate to do this, but the issue is still around in another form. After upgrading to the TC 8.5.18 which is currently under vote, Chrome fails to parse the jquery file with "SyntaxError: Unexpected Token ?" error. The response contains some data prior to the jQuery payload (it is probably encoding stuff) that throws Chrome off. Unfortunately I cannot pinpoint exactly what is going on. The original jQuery - the one I sent you with the testapp trying to reproduce the problem starts with "EF BB BF" before the actual The EF BB BF is called a Byte Order Mark (BOM) and is a marker to identify utf-8 coded files. A normal editor won't show those bytes. payload. When I run it through wget, the file on disk starts with just "3F". The response in Chrome looks like this: "0x62, 0x36, 0x65, 0x33, 0x0D, 0x0A, 0x3F" - so there is extra "b6e3\r\n" leading prior to the This looks like the length value that is needed for the chunked transfer. It is not part of the request content. Do you have set the fileEncoding property? Felix "3F". Below [1] is the request/response headers of the Chrome request. I've got also a HAR if this helps and I can send it to you email address as it will probably get stripped on the user-mailing list George Request Headers: GET http://hostname:8085/idp/javascript/jquery-1.8.3.min.js HTTP/1.1 Pragma: no-cache DNT: 1 Accept-Encoding: gzip, deflate Host: hostname:8085 Accept-Language: en-US,en;q=0.8,bg;q=0.6,und;q=0.4 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Accept: */* Cookie: JSESSIONID=blahblah Connection: keep-alive Cache-Control: no-cache Response headers: HTTP/1.1 200 Date: Thu, 20 Jul 2017 19:59:05 GMT X-Content-Type-Options: nosniff Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT ETag: W/"93640-1496825994000" X-Frame-Options: DENY Content-Type: application/javascript Transfer-Encoding: chunked Accept-Ranges: bytes X-XSS-Protection: 1; mode=block - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Issue with static file in Tomcat 8.5.17
>> The problem is related to the new code that handles the case when a >> file is stored in one encoding but served in another. Since changing >> encodings can change the value and number of bytes served (for example >> serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). >> This code did not handle requests that use accept-ranges correctly. > While the above is true, the actual problem looking more closely is that the > content length can change when conversion is used. >Mark Hi Mark, I hate to do this, but the issue is still around in another form. After upgrading to the TC 8.5.18 which is currently under vote, Chrome fails to parse the jquery file with "SyntaxError: Unexpected Token ?" error. The response contains some data prior to the jQuery payload (it is probably encoding stuff) that throws Chrome off. Unfortunately I cannot pinpoint exactly what is going on. The original jQuery - the one I sent you with the testapp trying to reproduce the problem starts with "EF BB BF" before the actual payload. When I run it through wget, the file on disk starts with just "3F". The response in Chrome looks like this: "0x62, 0x36, 0x65, 0x33, 0x0D, 0x0A, 0x3F" - so there is extra "b6e3\r\n" leading prior to the "3F". Below [1] is the request/response headers of the Chrome request. I've got also a HAR if this helps and I can send it to you email address as it will probably get stripped on the user-mailing list George Request Headers: GET http://hostname:8085/idp/javascript/jquery-1.8.3.min.js HTTP/1.1 Pragma: no-cache DNT: 1 Accept-Encoding: gzip, deflate Host: hostname:8085 Accept-Language: en-US,en;q=0.8,bg;q=0.6,und;q=0.4 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Accept: */* Cookie: JSESSIONID=blahblah Connection: keep-alive Cache-Control: no-cache Response headers: HTTP/1.1 200 Date: Thu, 20 Jul 2017 19:59:05 GMT X-Content-Type-Options: nosniff Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT ETag: W/"93640-1496825994000" X-Frame-Options: DENY Content-Type: application/javascript Transfer-Encoding: chunked Accept-Ranges: bytes X-XSS-Protection: 1; mode=block
Re: Issue with static file in Tomcat 8.5.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/8/17 3:06 PM, Mark Thomas wrote: > On 07/07/17 23:05, George Stanchev wrote: >> On 07/07/2017 20:56, George Stanchev wrote: >>> Sorry, I didn't realize there is a -d option that gives you the >>> full request and response. Here is the dump: >> >> Thanks for the extra information. >> >> I can't reproduce this yet. I'm going to hold off on closing the >> currently running votes until I get to the bottom of this. >> >> Which version of Windows is this? >> >> Mark >> >> >> >> We've reproduced it on Windows 7 and various versions of Windows >> Server (2016, 2012 R2, etc). All times Tomcat runs through the >> service wrapper. I happen to run it in the command line via >> >> start /b /wait %comspec% /c "%TOMCAT_EXE%" >> //TS//%TOMCAT_SERVICE_NAME% >> >> >> command. Here are more details. Since you cannot reproduce it, >> perhaps I can package up the tomcat + the test app in a zip and >> upload it somewhere... > > That would be helpful. I've tested this in multiple environments > and I can't reproduce it. Try creating a file with a mismatched character encoding so that the number of bytes sent over the wire doesn't match the number of bytes reported by File.length(). That jQuery file might do it on its own. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZZR74AAoJEBzwKT+lPKRYsbEP/AiEd9LXkLHdDXbTdR7o1o2b +c4m2aGnE9QLo1fatL8YXznTkVZonP+jBHU134buZgPkRJ0b/3ceXvmqK0hZJouJ UtmPWoLqMfb7m93zuE0Gi/GoI0OsnssW/awgGrY9EjF3LljCuAomUyHvcclTBo8r irv9hD3LnoZMA1hY9vDcHBnsCUsye/WtRpV1pifn0WE6UJOaygi7EUUcK8M5XCde ZGH7p7EVoiWTXLOSvOegzFysoxz5NktMaDrLn9A4hbe71EBvlBoctl7oLUAMylPn q2eLMDhxIABXJKLMJRXq0SqkyFgVC3gqyJhRQ39Lj9Hk4I/7aON+I2ty1aJ88Mjz UAPJ6L7u4d4EnmTCQN9hbhQ2cCeHr3bDTqJDIba3G+DDZ3/+UnACZMkzNMK8odrt j6qXVnjJut/Bk5I9md5sE2v4XM+6z6YLL+QtNeNRxDncES6OHJagENQdxCZqI+7f q9hQbWAnPvxROI3npqhR6rMJIHXrrx88DZLXPmOE5Vgy6bqo5FgOZkn6FuPUSQOh 44eMZPJbWV9H/6jtjx0fuYOSR/YGjCEjxEOjQfjzUm9mEgOqfxONkX5Z5B9q31x9 4N7JEcNIW2DuZzX6uFDciWSs57PRnY3I9d5nRydGuXaU7xilJ/G0eSmAchdt7e7h XIO7bR27JtAxImrPWVlN =ziQj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with static file in Tomcat 8.5.17
On Mon, Jul 10, 2017 at 3:31 PM, Mark Thomas wrote: > On 10/07/17 20:59, Mark Thomas wrote: > > On 08/07/17 20:06, Mark Thomas wrote: > >> On 07/07/17 23:05, George Stanchev wrote: > > > > > > > >>> Since you cannot reproduce it, perhaps I can package up the tomcat + > the > > test app in a zip and upload it somewhere... > >> > >> That would be helpful. I've tested this in multiple environments and I > >> can't reproduce it. > > > > Many thanks to George for putting together the test case. I have now > > been able to reproduce this. > > > > The problem is related to the new code that handles the case when a file > > is stored in one encoding but served in another. Since changing > > encodings can change the value and number of bytes served (for example > > serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). This > > code did not handle requests that use accept-ranges correctly. > > While the above is true, the actual problem looking more closely is that > the content length can change when conversion is used. > > Yes, so I think your fix is right: it's not possible to do a range request in that case. Rémy
Re: Issue with static file in Tomcat 8.5.17
On 10/07/17 20:59, Mark Thomas wrote: > On 08/07/17 20:06, Mark Thomas wrote: >> On 07/07/17 23:05, George Stanchev wrote: > > > >>> Since you cannot reproduce it, perhaps I can package up the tomcat + the > test app in a zip and upload it somewhere... >> >> That would be helpful. I've tested this in multiple environments and I >> can't reproduce it. > > Many thanks to George for putting together the test case. I have now > been able to reproduce this. > > The problem is related to the new code that handles the case when a file > is stored in one encoding but served in another. Since changing > encodings can change the value and number of bytes served (for example > serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). This > code did not handle requests that use accept-ranges correctly. While the above is true, the actual problem looking more closely is that the content length can change when conversion is used. Mark > > I am going to cancel the current 8.5.x and 9.0.x release votes, fix the > bug and re-roll the releases. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with static file in Tomcat 8.5.17
On 08/07/17 20:06, Mark Thomas wrote: > On 07/07/17 23:05, George Stanchev wrote: >> Since you cannot reproduce it, perhaps I can package up the tomcat + the test app in a zip and upload it somewhere... > > That would be helpful. I've tested this in multiple environments and I > can't reproduce it. Many thanks to George for putting together the test case. I have now been able to reproduce this. The problem is related to the new code that handles the case when a file is stored in one encoding but served in another. Since changing encodings can change the value and number of bytes served (for example serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). This code did not handle requests that use accept-ranges correctly. I am going to cancel the current 8.5.x and 9.0.x release votes, fix the bug and re-roll the releases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with static file in Tomcat 8.5.17
On 07/07/17 23:05, George Stanchev wrote: > > On 07/07/2017 20:56, George Stanchev wrote: >> Sorry, I didn't realize there is a -d option that gives you the full request >> and response. Here is the dump: > > Thanks for the extra information. > > I can't reproduce this yet. I'm going to hold off on closing the currently > running votes until I get to the bottom of this. > > Which version of Windows is this? > > Mark > > > > We've reproduced it on Windows 7 and various versions of Windows Server > (2016, 2012 R2, etc). All times Tomcat runs through the service wrapper. I > happen to run it in the command line via > > start /b /wait %comspec% /c "%TOMCAT_EXE%" //TS//%TOMCAT_SERVICE_NAME% > > > command. Here are more details. Since you cannot reproduce it, perhaps I can > package up the tomcat + the test app in a zip and upload it somewhere... That would be helpful. I've tested this in multiple environments and I can't reproduce it. Mark > > George > > > > 2017-07-07T16:00:53,409 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server built: > Jul 4 2017 08:12:51 UTC > 2017-07-07T16:00:53,410 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server > number: 8.5.17.0 > 2017-07-07T16:00:53,414 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Name: > Windows 7 > 2017-07-07T16:00:53,418 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Version: > 6.1 > 2017-07-07T16:00:53,422 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Architecture: > amd64 > 2017-07-07T16:00:53,427 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Java Home: > C:\Program Files\product\Common\jre1.8 > 2017-07-07T16:00:53,431 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Version: > 1.8.0_131-b11 > 2017-07-07T16:00:53,435 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Vendor: > Oracle Corporation > 2017-07-07T16:00:53,439 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- > CATALINA_BASE: C:\Program Files\product\Common\tomcat\server\default > 2017-07-07T16:00:53,444 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- > CATALINA_HOME: C:\Program Files\product\Common\tomcat > 2017-07-07T16:00:53,448 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Xms256M > 2017-07-07T16:00:53,452 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Xmx4096M > 2017-07-07T16:00:53,457 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -XX:+UseConcMarkSweepGC > 2017-07-07T16:00:53,461 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Dsun.rmi.dgc.client.gcInterval=360 > 2017-07-07T16:00:53,465 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Dsun.rmi.dgc.server.gcInterval=360 > 2017-07-07T16:00:53,470 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Xdebug > 2017-07-07T16:00:53,475 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: > -Xrunjdwp:transport=dt_socket,address=localhost:8000,server=y,suspend=n > 2017-07-07T16:00:53,480 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Dcatalina.home=C:\Program Files\product\Common\tomcat > 2017-07-07T16:00:53,484 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Dcatalina.base=C:\Program > Files\product\Common\tomcat\server\default > 2017-07-07T16:00:53,488 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > 2017-07-07T16:00:53,493 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Dlog4j.configurationFile=C:\Program > Files\product\Common\tomcat\server\default\conf\log4j2.xml > 2017-07-07T16:00:53,497 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager > 2017-07-07T16:00:53,501 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line > argument: -Djava.io.tmpdir=C:\Program > Files\product\Common\tomcat\server\default\temp > 2017-07-07T16:00:53,514 INFO [main] > [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Comman
RE: Issue with static file in Tomcat 8.5.17
On 07/07/2017 20:56, George Stanchev wrote: > Sorry, I didn't realize there is a -d option that gives you the full request > and response. Here is the dump: Thanks for the extra information. I can't reproduce this yet. I'm going to hold off on closing the currently running votes until I get to the bottom of this. Which version of Windows is this? Mark We've reproduced it on Windows 7 and various versions of Windows Server (2016, 2012 R2, etc). All times Tomcat runs through the service wrapper. I happen to run it in the command line via start /b /wait %comspec% /c "%TOMCAT_EXE%" //TS//%TOMCAT_SERVICE_NAME% command. Here are more details. Since you cannot reproduce it, perhaps I can package up the tomcat + the test app in a zip and upload it somewhere... George 2017-07-07T16:00:53,409 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server built: Jul 4 2017 08:12:51 UTC 2017-07-07T16:00:53,410 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server number: 8.5.17.0 2017-07-07T16:00:53,414 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Name: Windows 7 2017-07-07T16:00:53,418 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Version: 6.1 2017-07-07T16:00:53,422 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Architecture: amd64 2017-07-07T16:00:53,427 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Java Home: C:\Program Files\product\Common\jre1.8 2017-07-07T16:00:53,431 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Version: 1.8.0_131-b11 2017-07-07T16:00:53,435 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Vendor: Oracle Corporation 2017-07-07T16:00:53,439 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- CATALINA_BASE: C:\Program Files\product\Common\tomcat\server\default 2017-07-07T16:00:53,444 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- CATALINA_HOME: C:\Program Files\product\Common\tomcat 2017-07-07T16:00:53,448 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Xms256M 2017-07-07T16:00:53,452 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Xmx4096M 2017-07-07T16:00:53,457 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -XX:+UseConcMarkSweepGC 2017-07-07T16:00:53,461 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dsun.rmi.dgc.client.gcInterval=360 2017-07-07T16:00:53,465 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dsun.rmi.dgc.server.gcInterval=360 2017-07-07T16:00:53,470 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Xdebug 2017-07-07T16:00:53,475 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Xrunjdwp:transport=dt_socket,address=localhost:8000,server=y,suspend=n 2017-07-07T16:00:53,480 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dcatalina.home=C:\Program Files\product\Common\tomcat 2017-07-07T16:00:53,484 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dcatalina.base=C:\Program Files\product\Common\tomcat\server\default 2017-07-07T16:00:53,488 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 2017-07-07T16:00:53,493 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dlog4j.configurationFile=C:\Program Files\product\Common\tomcat\server\default\conf\log4j2.xml 2017-07-07T16:00:53,497 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager 2017-07-07T16:00:53,501 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Djava.io.tmpdir=C:\Program Files\product\Common\tomcat\server\default\temp 2017-07-07T16:00:53,514 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Duser.country=US 2017-07-07T16:00:53,518 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dfile.encoding=UTF-8 2017-07-07T16:00:53,522 INFO [main] [org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line argument: -Dserver.log.dir=C:\Program Files\product
Re: Issue with static file in Tomcat 8.5.17
On 07/07/2017 20:56, George Stanchev wrote: > Sorry, I didn't realize there is a -d option that gives you the full request > and response. Here is the dump: Thanks for the extra information. I can't reproduce this yet. I'm going to hold off on closing the currently running votes until I get to the bottom of this. Which version of Windows is this? Mark > > > c:\>wget -d -S http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc > syswgetrc = C:\bin\gnuwin32/etc/wgetrc > Setting --server-response (serverresponse) to 1 > DEBUG output created by Wget 1.11.4 on Windows-MinGW. > > --2017-07-07 13:52:36-- > http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > Resolving hostname... seconds 0.00, , ... > Caching hostname => > Connecting to hostname:8085... seconds 0.00, connected. > Created socket 336. > Releasing 0x00339048 (new refcount 1). > > ---request begin--- > GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0 > User-Agent: Wget/1.11.4 > Accept: */* > Host: hostname:8085 > Connection: Keep-Alive > > ---request end--- > HTTP request sent, awaiting response... > ---response begin--- > HTTP/1.1 200 > X-Frame-Options: DENY > X-Content-Type-Options: nosniff > X-XSS-Protection: 1; mode=block > Accept-Ranges: bytes > ETag: W/"93640-1496825994000" > Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT > Content-Type: application/javascript > Content-Length: 93640 > Date: Fri, 07 Jul 2017 19:52:36 GMT > Connection: keep-alive > > ---response end--- > > HTTP/1.1 200 > X-Frame-Options: DENY > X-Content-Type-Options: nosniff > X-XSS-Protection: 1; mode=block > Accept-Ranges: bytes > ETag: W/"93640-1496825994000" > Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT > Content-Type: application/javascript > Content-Length: 93640 > Date: Fri, 07 Jul 2017 19:52:36 GMT > Connection: keep-alive > Registered socket 336 for persistent reuse. > Length: 93640 (91K) [application/javascript] > Saving to: `jquery-1.8.3.min.js.3' > > 99% [...] 93,638 89.5K/s in 23s > > 2017-07-07 13:53:00 (3.96 KB/s) - Connection closed at byte 93638. Retrying. > > --2017-07-07 13:53:01-- (try: 2) > http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > Disabling further reuse of socket 336. > Closed fd 336 > Found hostname in host_name_addresses_map (00339048) > Connecting to hostname|:8085... seconds 0.00, connected. > Created socket 336. > Releasing 0x00339048 (new refcount 1). > > ---request begin--- > GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0 > Range: bytes=93638- > User-Agent: Wget/1.11.4 > Accept: */* > Host: hostname:8085 > Connection: Keep-Alive > > ---request end--- > HTTP request sent, awaiting response... > ---response begin--- > HTTP/1.1 206 > X-Frame-Options: DENY > X-Content-Type-Options: nosniff > X-XSS-Protection: 1; mode=block > Accept-Ranges: bytes > ETag: W/"93640-1496825994000" > Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT > Content-Range: bytes 93638-93639/93640 > Content-Type: application/javascript > Content-Length: 2 > Date: Fri, 07 Jul 2017 19:53:01 GMT > Connection: keep-alive > > ---response end--- > > HTTP/1.1 206 > X-Frame-Options: DENY > X-Content-Type-Options: nosniff > X-XSS-Protection: 1; mode=block > Accept-Ranges: bytes > ETag: W/"93640-1496825994000" > Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT > Content-Range: bytes 93638-93639/93640 > Content-Type: application/javascript > Content-Length: 2 > Date: Fri, 07 Jul 2017 19:53:01 GMT > Connection: keep-alive > Registered socket 336 for persistent reuse. > Length: 93640 (91K), 2 remaining [application/javascript] > Saving to: `jquery-1.8.3.min.js.3' > > 100%[...] 93,640 --.-K/s in 0s > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Issue with static file in Tomcat 8.5.17
Sorry, I didn't realize there is a -d option that gives you the full request and response. Here is the dump: c:\>wget -d -S http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:\bin\gnuwin32/etc/wgetrc Setting --server-response (serverresponse) to 1 DEBUG output created by Wget 1.11.4 on Windows-MinGW. --2017-07-07 13:52:36-- http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js Resolving hostname... seconds 0.00, , ... Caching hostname => Connecting to hostname:8085... seconds 0.00, connected. Created socket 336. Releasing 0x00339048 (new refcount 1). ---request begin--- GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: hostname:8085 Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Type: application/javascript Content-Length: 93640 Date: Fri, 07 Jul 2017 19:52:36 GMT Connection: keep-alive ---response end--- HTTP/1.1 200 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Type: application/javascript Content-Length: 93640 Date: Fri, 07 Jul 2017 19:52:36 GMT Connection: keep-alive Registered socket 336 for persistent reuse. Length: 93640 (91K) [application/javascript] Saving to: `jquery-1.8.3.min.js.3' 99% [...] 93,638 89.5K/s in 23s 2017-07-07 13:53:00 (3.96 KB/s) - Connection closed at byte 93638. Retrying. --2017-07-07 13:53:01-- (try: 2) http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js Disabling further reuse of socket 336. Closed fd 336 Found hostname in host_name_addresses_map (00339048) Connecting to hostname|:8085... seconds 0.00, connected. Created socket 336. Releasing 0x00339048 (new refcount 1). ---request begin--- GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0 Range: bytes=93638- User-Agent: Wget/1.11.4 Accept: */* Host: hostname:8085 Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 206 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Range: bytes 93638-93639/93640 Content-Type: application/javascript Content-Length: 2 Date: Fri, 07 Jul 2017 19:53:01 GMT Connection: keep-alive ---response end--- HTTP/1.1 206 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Range: bytes 93638-93639/93640 Content-Type: application/javascript Content-Length: 2 Date: Fri, 07 Jul 2017 19:53:01 GMT Connection: keep-alive Registered socket 336 for persistent reuse. Length: 93640 (91K), 2 remaining [application/javascript] Saving to: `jquery-1.8.3.min.js.3' 100%[...] 93,640 --.-K/s in 0s - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Issue with static file in Tomcat 8.5.17
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, July 07, 2017 1:05 PM To: Tomcat Users List Subject: Re: Issue with static file in Tomcat 8.5.17 On 07/07/2017 19:09, George Stanchev wrote: > Hi, .. > Please let me know if I need to open a BZ issue to track this. I have a test > app but really it is very simple - an app with empty web descriptor and that > version of minimized jQuery JS in a folder. The most likely suspect is this fix: 49464: Improve the Default Servlet's handling of static files when the file encoding is not compatible with the required response encoding. (markt) What is your system's default file encoding (or if you have done so, what is explicitly configured for the DefaultServlet?). The full response headers would also be helpful. Thanks, Mark We run with -Dfile.encoding=UTF-8. Here is more verbose response [1]. It takes ~20secs for the first request to time out. [1] c:\>wget -S http://host:8085/testapp/javascript/jquery-1.8.3.min.js SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:\bin\gnuwin32/etc/wgetrc --2017-07-07 13:08:48-- http://host:8085/testapp/javascript/jquery-1.8.3.min.js Resolving... hostnames ... Connecting to host:8085... connected. HTTP request sent, awaiting response... HTTP/1.1 200 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Type: application/javascript Content-Length: 93640 Date: Fri, 07 Jul 2017 19:08:48 GMT Connection: keep-alive Length: 93640 (91K) [application/javascript] Saving to: `jquery-1.8.3.min.js.2' 99% [=> ] 93,638 86.5K/s in 20s 2017-07-07 13:09:08 (4.57 KB/s) - Connection closed at byte 93638. Retrying. --2017-07-07 13:09:09-- (try: 2) http://host/testapp/javascript/jquery-1.8.3.min.js Connecting to host:8085... connected. HTTP request sent, awaiting response... HTTP/1.1 206 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes ETag: W/"93640-1496825994000" Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT Content-Range: bytes 93638-93639/93640 Content-Type: application/javascript Content-Length: 2 Date: Fri, 07 Jul 2017 19:09:09 GMT Connection: keep-alive Length: 93640 (91K), 2 remaining [application/javascript] Saving to: `jquery-1.8.3.min.js.2' 100%[++>] 93,640 --.-K/s in 0s 2017-07-07 13:09:09 (69.2 KB/s) - `jquery-1.8.3.min.js.2' saved [93640/93640]
Re: Issue with static file in Tomcat 8.5.17
On 07/07/2017 19:09, George Stanchev wrote: > Hi, > > The current Tomcat 8.5.17 is under vote for release with +1s only. I took the > liberty to download the distributable before officially announced and am > running into an issue with it. Static file that used to download in 8.5.16 > and below now it doesn't. Chrome reports: > > jquery-1.8.3.min.js:1 GET > http://rm9485:8085/testapp/javascript/jquery-1.8.3.min.js > net::ERR_CONTENT_LENGTH_MISMATCH > > In its console > > If I try wget, it eventually succeeds but not without a retry: > > c:\>wget http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc > syswgetrc = C:\bin\gnuwin32/etc/wgetrc > --2017-07-07 11:58:40-- > http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > Resolving hostname, IPs, etc, ... > Connecting to hostname:8085... connected. > HTTP request sent, awaiting response... 200 > Length: 93640 (91K) [application/javascript] > Saving to: `jquery-1.8.3.min.js' > > 99% > [=> > ] 93,638 85.5K/s in 21s > > 2017-07-07 11:59:02 (4.34 KB/s) - Connection closed at byte 93638. Retrying. > > --2017-07-07 11:59:03-- (try: 2) > http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js > Connecting to ***:8085... connected. > HTTP request sent, awaiting response... 206 > Length: 93640 (91K), 2 remaining [application/javascript] > Saving to: `jquery-1.8.3.min.js' > > 100%[++>] > 93,640 --.-K/s in 0s > > 2017-07-07 11:59:03 (49.3 KB/s) - `jquery-1.8.3.min.js' saved [93640/93640] > > > Please let me know if I need to open a BZ issue to track this. I have a test > app but really it is very simple - an app with empty web descriptor and that > version of minimized jQuery JS in a folder. The most likely suspect is this fix: 49464: Improve the Default Servlet's handling of static files when the file encoding is not compatible with the required response encoding. (markt) What is your system's default file encoding (or if you have done so, what is explicitly configured for the DefaultServlet?). The full response headers would also be helpful. Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
