首页 » App开发 » nginx 页面报ERR_CONTENT_DECODING_FAILED

nginx 页面报ERR_CONTENT_DECODING_FAILED

nginx 页面报ERR_CONTENT_DECODING_FAILED

近日,将WordPress搭建的站点创意应用迁移到了nginx上,因为WP实在是很慢,所以一直有用缓存插件,之前在Apache下面使用的是wp-super-cache,转到nginx上后,wp-super-cache同样可以使用,只是需要配置一下站点的config,基本上按着教程来就是了。但是使用之后,发现缓存了的页面加载很快,未缓存的页面按道理应该是直接到php上进行处理并把页面缓存下来供下次访问使用,但是我发现这边不是的,在使用chrome访问时,会出现一个错误页面一闪而过,然后跳转到内容页,如果是使用IE和Safari,会直接提示页面错误(没详细信息)而进不去页面,需要再刷新一次才能进页面。一开始以为是wp-super-cache和nginx不兼容,于是换用了插件w3-total-cache,一番修改和配置后,w3-total-cache也可用了,然而问题依旧。
于是想起chrome的一闪而过的错误页面,录屏后发现报的是Error 330 (net::ERR_CONTENT_DECODING_FAILED):。当然有详细的错误信息就好找解决方案了。

It happens when your HTTP request’s headers claim that the content is gzip encoded, but it isn’t.

cache插件会将response的编码格式设置为Content-Encoding:gzip,然而如果请求没有命中缓存,而是直接落到了php上,php-fpm在默认情况下并没有启用gzip压缩。于是就出现了申明为gzip而实际使用的是另一种,对于这种response,chrome很有良心的再请求了一次,而IE和Safari就直接报错了。因为第一次请求已经产生了缓存,第二次再请求已经会命中缓存了,所以第二次都可以打开页面。

找出原因后,可以视需求来解决,可以把插件的gzip压缩关闭,也可以将php.inizlib.output_compression从默认的Off改成On,总之内容和申明的编码格式一致即可。

这次机缘巧合的接触了w3-total-cache,感觉这个插件比wp-super-cache强大许多,也复杂很多,现在我使用的只是它的page cache,它还支持database cache、object cache和CDN及js/css minify功能。而且db cache和object cache还可以缓存在memerchache 和redis上,想想都是激动,计划下周找个时间试试缓存内容到redis上。