On 30/07/17 13:39, Konstantin Preißer wrote:
> Hi Mark,
> 
>> -----Original Message-----
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Sunday, July 30, 2017 12:40 PM
>>
>> (...)
>>
>>> Stuff breaking is unintentional and is a bug. Unfortunately, it appears
>>> that you have stumbled across a bug that wasn't detected in any of the
>>> last three attempted releases.
>>>
>>> I think (but I can't be sure without a test case) the problem stems from
>>> the case where a character set is not explicitly defined for the
>>> response. If that is the case, it should be a fairly simple fix.
>>>
>>> My preference is to keep the edge case handling I recently added if at
>>> all possible and prevent the conversion from applying when it is not
>>> required.
>>
>> Konstantin,
>>
>> If you can try one of the following patches and report back whether it
>> fixes the problem that would be very helpful.
>>
>> Tomcat 9.0.x
>> http://home.apache.org/~markt/patches/2017-07-30-default-servlet-
>> encoding-tc9-v1.patch
>>
>> Tomcat 8.5.x
>> http://home.apache.org/~markt/patches/2017-07-30-default-servlet-
>> encoding-tc85-v1.patch
> 
> Thank you very much for your fast feedback. I applied the patch for Tomcat 
> 8.5.x and it seems to fix the issue: Static text/JavaScript files are served 
> untouched (their encoding is not changed), which means JavaScript files 
> encoded as UTF-8 (without BOM) are working again in the browser.

Thanks for the confirmation.

The more I think about this, the more I'm leaning towards your
suggestion of reverting it for 8.5.x and below anyway.

It should just be addressing the edge cases it was intended to but there
have been too many unintended consequences for my liking.

I'll start that discussion on the dev list.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to