Thanks a lot Mark,the issue is solved now. It turns out that his Mac had the
old CompressingFilter enabled which is old open-source gzip compression library
found on source forge,that our system had been using back in the day of tomcat
5., because I believe at that time tomcat didn't support gzip, compression out
of the box. When we switched to tomcat 7 in 2016, the jar was copied from our
lib dir tomcat 5 and we had no problems using it, although tomcat 7 already had
gzip out of box. When we switched to tomcat 9 last year on both our servers we
had some issues with it enabled, because unlike the 7, we had another server in
front of tomcat for single sign-on capabilities. we have since disabled it on
our servers. But because of sso we don't actually store web.xml in git, just
its copy with the sample extension in git., there is always room for copy-paste
errors. As soon as you mentioned ContentLength I've remembered the trouble
with the compressingFilter from last year and mentioned that to my colleague,
and 5 minutes later he comes back to me with the good news. Once he had removed
the filter mapping for CompressingFilter he had no problems with the js file.
The mapping itself was for java-scripts folder in our project, which is where
the problematic file was. This explains why we couldn't find the solution when
using our test server, since the filter jar wasn't on these servers. Thanks
again Mark and Chris for steering me in the right direction.
