Invalid IIS Content Type for Compressed CSS

I am developing a part of the ASP.NET site that uses mainly themes, but has a couple of CSS files in the themes folder. They are included in web.config by another developer, for example:

<Content Include="App_Themes\SoftOrange\CMSStyles.css" /> <Content Include="App_Themes\SoftOrange\ContentStyles.css" /> 

Our internal test server (IIS7, Server 2008 R2 Enterprise) includes global IIS Manager settings for static and dynamic compression for files larger than 2700 bytes. Static and dynamic compression for the site is also included.

At some point (perhaps when CMSStyles.css hit 2700 bytes), some styles were filled - i.e. were clearly not loaded looking at the page. I found that the content type (according to firefox 7.0.1) shows text / css, and when I loaded the URL for CMSStyles.css, it looked like regular compressed garbage in a text editor:

  β€Ή      
etc. IE doesn't open the css file directly, but when I use the developer tools to display css, it looks empty.

I turned off static content compression only for this site, and CSS files now load properly. My question is why ?! Is it a content type issue, Content-Encoding, or is it an IIS problem or a problem with how CSS is used in a web application?

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 header

  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 seems that the encoding of the content is corrent: gzip.

+3
source share
1 answer

The problem here (from my experience in similar issues) is Content-Length .

Check if Content-Length is installed in any part of your code, remove it and it will work again. Why is this? because if you set the Content-Length on header, IIS will then not be able to change it to compressed, and gzip decompression will fail. Why was IIS unable to change it? because by default, if you set the title in IIS, that title remains and cannot be changed (especially if you start it early). There is a flag that allows IIS to change it after installing it, but it is best to avoid installing it.

Related issues: ASP.NET sometimes freezes and / or displays odd text at the top of the page when loading on load-balanced servers

Update

From @thinkOfaNumber: Turns out I used devexpress compression as well as IIS compression . I disabled devexpress compression in web.config and it works!

What is displayed here is that the first compression sets the Content-Length , and the second compression cannot change it, because the Content-Length writes the header, and the header cannot change * after you set it, so the second compression change The final compressed side, as a result of which the browser will not be able to read it correctly, and then will not be able to open it correctly.

[*] There is a way to change the headers after sending them to IIS and before sending them to the browser, and this can be done with changing the default IIS behavior, but it’s not so simple, and I do not know if it can solve this problem.

+1
source

All Articles