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
