在Chrome上预压缩gzip中断，为什么？ [英] pre-compressed gzip break on chrome, why?

问题描述

我在我的网站上提供了预压缩的CSS和JS文件，IE6-8和FF
可以与我的.htaccess文件完美配合。

 ＃压缩文件
 RewriteCond％{HTTP：Accept-Encoding}。* gzip。* 
 AddEncoding x-gzip .gz 
 AddType application / x-javascript .gz 
 AddType text / css .gz 
  

我使用扩展名为.gz的文件已经[示例]：

 < link rel =stylesheettype =text / cssmedia =allhref =css / layout.css.gz/> 
  

那么为什么Google Chrome浏览器会崩溃？

谢谢。

=nofollow noreferrer> Fiddler ，并查看原始响应标头，以查看服务器针对该特定请求发回的内容。

FYI，Fiddler是一个客户端代理，用于过滤浏览器请求。在处理这些问题时提供超级信息。

- 更新

经过进一步调查，似乎你的RewriteCond实际上并没有做你认为正在做的事情。根据文档，RewriteCond指令仅用于与RewriteRule结合。

I serve pre-compressed CSS and JS files on my site, and IE6-8 and FF is working perfectly with my .htaccess file.

# Compressed files
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
AddEncoding x-gzip .gz
AddType application/x-javascript .gz
AddType text/css .gz

I call the files with the .gz extension already [example]:

<link rel="stylesheet" type="text/css" media="all" href="css/layout.css.gz" />

So why is this breaks in google Chrome?

Thanks.

解决方案

Download Fiddler and look at the raw response headers to see what the server is sending back for that particular request.

FYI, Fiddler is a client side proxy that filters your browser requests through. Super informative when dealing with these kind of issues.

-- Update

Upon further investigation, it doesn't appear that your RewriteCond is actually doing what you think it is doing. According to the Documentation, the RewriteCond directive is only used in conjunction with a RewriteRule.

这篇关于在Chrome上预压缩gzip中断，为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！