On 5/19/20 09:50, Martin Grigorov wrote: >> Hi, >> >> On Tue, May 19, 2020 at 3:32 PM Tuukka Ilomäki >> <tuukka.ilom...@teosto.fi> wrote: >> >>> Dear collective wisdom, as the EOL of Tomcat 7 is looming, we are >>> migrating our legacy app from Tomcat 7.0 to Tomcat 8.5. We deploy >>> exactly the same war in both versions. For some reason Tomcat 8.5 >>> adds null characters to the end of JavaScript files. For >>> instance, jQuery file served by Tomcat 8.5 ends with “})( window >>> ); �����” where five last characters are bytes 00. Tomcat 7.0 >>> serves the same file correctly. In case it matters, the issue >>> occurs in both windows 10 and windows server 2016 environments. >>> >>> I assume this has something to do with character encoding. >>> Original js-file is cp1252. I have perused Tomcat 8 migration >>> guide and Tomcat encoding FAQ and experimented with the various >>> options but so far with no luck. Any advice is greatly >>> appreciated. >>> >> >> I'd advise you to convert your files to UTF-8. Or tell Tomcat to >> write responses in your preferred encoding.
I would prefer keeping CP1252 for two reasons. First, for a test period we can keep the same codebase for production running in Tomcat 7 and test running Tomcat 8.5. Secondly, initial experiments with UTF-8 caused failures in backend RPG call to AS400 (trailing nulls again there as well). “tell Tomcat to write responses in your preferred encoding” is exactly what I am trying to do but it seems that I have not found all the places where I need to tell it. >Tailing nulls might also be a misinterpreted chunked response. (I'm >grasping at straws, here). > >Tuukka, is your client communicating directly with Tomcat, or through >some kind of proxy or load balancer? > >I've been using the same product with Tomcat since the 4.1 series, and >I upgraded through every single major version from there to 9.0. I've >never seen anything like that. In production environment we have httpd in front of Tomcat but now in testing phase we communicate directly to Tomcat. My wild guess is that response size is calculated using UTF-8 but response is cp1252. This is suggested by the fact that if I add comment line “// ääää” that has four characters that are double-byte characters in UTF-8, then the file served by Tomcat has four more null bytes appended. Having first written all of the above and after some serious digging deep into the bowels of legacy code it turned out that a filter was setting the encoding. (Following the golden rules of legacy code, no one remembers the rational for that piece of code.) For unknown reasons it had worked for almost a decade in Tomcat 7 but Tomcat 8.5 did not like it. The reason for the different behavior remains unknown, but I have found where to start tinkering. Thanks to all for the suggestions – much appreciated. Tuukka
