Nginx和Tomcat同时启用GZIP的后果

新部署的一台服务器在做了性能调优以后发现FCK在线编辑器IE、firefox都出现报错,只有chrome正常。百思不得其解,差点就把FCK换掉。经过千辛万苦终于找到了原因(本人找错误原因的运气一直都非常好):

 

开始以为是脚本乱码,看了文件头的那段注释以后确认不是这个问题。

 

在firefox的firedebug上面看到的脚本一直报找不到对象的错误,难道是公司的网络龟速导致脚本加载顺序不协调所致?几次刷新以后问题还在,304状态码说明不是网络龟速的原因。

 

最后把FCK的javascript脚本下载到本地以后一看,只有20k左右,而完整的是249K,看来我找到原因了~~

 

还是百思不得其解,好好的静态脚本文件为什么会下载了一部分就完了呢?而且首次下载的状态码是200,之后的刷新都是304,这违反了我对HTTP状态码的理解。

 

撇开前端的Nginx,直接访问tomcat居然页面就正常了。so~问题在nginx。nginx处理静态资源的能力从来都没有怀疑过(这再次违反了我对XXX的理解)。

 

灵光一闪,前后端的服务器最近都进行了调优,难道是这次修改了配置文件导致的?so首先关闭nginx的gzip  off;,重启Nginx后全世界正常了。随后关闭后端tomcat的compression="off",重新启用Nginx的gzip,问题终于解决了。

 

总结:多层服务器结构的系统启用gzip压缩要注意一个问题:前端服务器启用了gzip以后,后端的服务器就不要启用gzip压缩了,不然部分浏览器会下载到不完整的文件。

 

 

你可能感兴趣的:(tomcat,nginx,GZip)