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
