4

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_Themes\SoftOrange\CMSStyles.css" />
<Content Include="App_Themes\SoftOrange\ContentStyles.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.

thinkOfaNumber
  • 2,581
  • 3
  • 27
  • 46

1 Answers1

2

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.

Community
  • 1
  • 1
Aristos
  • 66,005
  • 16
  • 114
  • 150
  • strange... With compression set, and doing ctrl-refresh to clear the cache every time I load, I get varying responses: `Content-Length 1728` and the style sheet is zipped and broken, `Content-Length 1297` and the style sheet is zipped and working... – thinkOfaNumber Apr 13 '12 at 07:05
  • ok sorry for being a noob, but I was applying the changes without restarting the app. So as it turns out, the content-length is changing for this CSS file when compression is turned on... pardon my French, but wtf? – thinkOfaNumber Apr 13 '12 at 07:13
  • @thinkOfaNumber You may get different length because the gzip is make dynamic compress and maybe this change. The think is to not set it pro grammatically inside your code. – Aristos Apr 13 '12 at 08:44
  • I'm not setting it programatically anywhere. Strange that the numbers are always the same (1728 or 1297) and one is always broken, one always works... – thinkOfaNumber Apr 16 '12 at 05:02
  • @thinkOfaNumber maybe some module set it, or maybe there is a double compress somehow... from two different modules. – Aristos Apr 16 '12 at 09:06
  • Your last "guess" was correct - 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! Should I make my own answer for this or mark yours? – thinkOfaNumber Jun 28 '12 at 06:07
  • @thinkOfaNumber Better accept this one because actually I say that the issue is the double compress and the fail to change the content-length . So I have update my question with your details. – Aristos Jun 28 '12 at 07:12
  • 1
    This topic is old, but I had the same issue just now. It really was double compression: GZIP from the Web-app and compression from the IIS StaticCompressionModule. – spaark May 29 '20 at 05:21