问题还原
上午给老板展示的时,一直正常运行的网页一直在加载中,怎么都无法打开。使用chrome的开发者模式进行排查时,发现百度的开源编辑器umeditor中的js文件一直无法正常加载,返回状态码为206,每次刷新加载出来的文件大小都不一样。
怀疑1
最开始我怀疑的是网络的问题,因为一直以来该网页都是正常的,但是最后使用另外一台电脑打开时同样的问题也发生了。
怀疑2
我尝试用wget和curl进行将文件下载,但是比较奇怪的是都是开始下载非常快,但是一旦到了一定的地方,就无法下载了。
怀疑3
我猜测是服务器的问题,但是服务器我一直都没有动过。开始文件在NGINX服务器中,然后我将文件移动到Tomcat服务器中,发现问题依然存在。
怀疑4
在网络上进行搜索206和nginx发现貌似遇到问题的人的确不少,有的是CSS/JS/PNG等等。解决的方法也是千奇百怪,例如删除NGINX的LOGS文件后重启就正常了,还有的就是对缓存区进行扩大,但是这些解决方法对我都没有什么效果,无奈抛弃网络继续自己寻找原因和解决办法。
怀疑5
经过测试,其他文件都下载正常,只有这2个js文件无法下载,一个大约390KB,一个大约180KB,于是我从网上另外寻找了几个差不多大小的库,进行测试,发现均正常。至此,基本可以断定就是umeditor中的js文件在捣鬼。
另外,我还找了其他几个高低版本,JSP/PHP版本,GBK/UTF8版本进行测试,均有该问题发生,然后重新自己压缩,删注释,修改文档为UNIX的回车符,修改文档为UTF8/GBK等多种方法进行测试,均无法正常使用,非常神奇。
修改名字,发现也无法正常下载,万般无奈之下决定尝试压缩以后进行下载,正常,更加无奈了。
解决方法
但是在怀疑5的测试中,发现压缩后下载正常,虽然比较无奈但是却让我想到了一种可能的原因,是否是该JS文件的某些字符会让下载的过程中误以为传输完毕呢?虽然感觉有点扯,不过刚好想到目前HTML5的浏览器都支持GZIP网页压缩,而NGINX服务器刚好也支持GZIP网页压缩,于是我就将NGINX的GZIP网页压缩选项打开,发现内容正常了。解决方法:NGINX开启GZIP压缩
最后
最后把我的服务器软件写一下:Debian 9 + NGINX 1.14.0
对了,这个问题我并没有上交到umeditor的github上,最主要的原因是项目好久都没更新了,另外一方面,这个问题开始是正常的,而且,我将内容移动到其他的服务器上也是一直正常的,我没有办法将问题进行重现。
这个问题最奇特的地方是在于一直运行正常,突然间就发生了,然后重新将文件上传以后也无法恢复。一般都是服务器的原因导致无法正常加载,这次是有针对性的针对某个JS和他的压缩版本JS,还是比较玄学的,不过编程一直就是一件挺玄学的事情,不是么??