问题描述
I develop part of an ASP.NET site that uses mostly themes but has a couple of CSS files in the themes folder. These are included in the web.config by another developer like so:
<Content Include="App_ThemesSoftOrangeCMSStyles.css" />
<Content Include="App_ThemesSoftOrangeContentStyles.css" />
On our internal test server (IIS7, Server 2008 R2 Enterprise) the global IIS manager options for static and dynamic compression are on, for files larger than 2700 bytes. The site-specific static and dynamic compression are also enabled.
At some point (probably when CMSStyles.css hit 2700 bytes) some styles got stuffed - ie. were obviously not loading by looking at the page. I found that the content-type (according to firefox 7.0.1) was showing text/css, and when I loaded the URL for CMSStyles.css it looked like normal compressed junk in a text editor:
‹�����
etc. IE doesn't directly open the css file, but when I use developer tools to show the css, it appears empty.
I turned off static content compression just for this site, and the CSS files now load properly. My question is why?! Is it a content-type problem, Content-Encoding, or is this an IIS problem, or a problem with the way the CSS is used in the web app?
thanks.
EDIT:
These are the headers for the GET request for CMSStyles.css: Response Headers
Accept-Ranges bytes Content-Encoding gzip Content-Length 1728 Content-Type text/css Date Fri, 13 Apr 2012 01:22:43 GMT Etag "80a762a82cecd1:0" Last-Modified Fri, 30 Mar 2012 04:22:03 GMT Persistent-Auth true Server Microsoft-IIS/7.5 Vary Accept-Encoding X-Powered-By ASP.NET
Request Headers
Accept text/css,*/*;q=0.1 Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding gzip, deflate Accept-Language en-gb,en;q=0.5 Connection keep-alive Cookie -removed- Host -removed- Referer -removed- User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
so it looks like the content-encoding is corrent: gzip.
The issue here (from my experiences in similar problems) is the Content-Length.
Check if you set the Content-Length in any part of your code, remove it and it will work again. Why is that ? because if you set the Content-Length on header the IIS then fail to change it to the compressed one, and the decompress of the gzip fails. Why IIS fail to change it ? because by default if you set a header on IIS this header remain and can not be change (especially if you flush it early). There is a flag that let IIS change it after you set it but its better just to avoid to set it.
Similar questions: ASP.NET site sometimes freezing up and/or showing odd text at top of the page while loading, on load balanced servers
Update
From the @thinkOfaNumber : It turns out I was using devexpress compression as well as IIS compression. I turned off devexpress compression in the web.config and it works!
What is show here is that the first compression set the Content-Length and the second compression fail to change it because Content-Length is write on header and header can not change* after you have set it, so the second compression change the final compressed side with result that the browser fail to read it correct, and then fail to decompress it correct.
[*] There is a way to change the headers after you have send them on IIS, and before send them to the browser, and this can be done with changing the default behavior of IIS but is not so easy and I do not know if can solve this issue.
这篇关于压缩 CSS 的 IIS 内容类型错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！