Content type getting lost?

Feb 9, 2011 at 5:15 AM
Edited Mar 11, 2011 at 6:00 PM

Every so often on our site the combres files will stop getting served with the Content-Type header, both css & js.  This causes a problem in firefox but it is a pretty big problem, the pages are unstyled and none of the js works.  We are hosting on azure and a reboot of the servers fixes it.  Haven't been able to pick up a pattern of when it happens or for how long, we are normally notified by customers that it is a problem.

Feb 11, 2011 at 2:03 PM

We ran into this problem doing IE9 testing. I believe we fixed it by adding;

Context.Response.ContentType = ResourceSet.Type == ResourceType.JS ? "application/x-javascript" : "text/css";

to RequestProcessor.cs's IsInBrowserCache function. Seems to consistently send the content-type header now.

Feb 14, 2011 at 10:42 AM

I've modified the code to set the content type at the very top.  Please give it a try and let me know if the issue persists.

Feb 14, 2011 at 9:30 PM

I will try out the newest version today.  No luck with the fix from orcnbeans, happened again this morning :|

Feb 15, 2011 at 9:20 PM

Deployed the update last night.  Everything going good until just now, happened again :(

Any other ideas, or some other data I can capture to help point in the right direction?

Feb 16, 2011 at 12:45 PM

That's strange.  Can you share the log file segment corresponding to the erroneous request?  

Feb 16, 2011 at 6:06 PM

Next time it happens I will grab a log file.

I combined your code with orcnbeans' code last night and so far no issues.  It definitely happens more often when we have higher traffic levels, we'll see how it progresses throughout today.

Feb 19, 2011 at 7:53 PM

doh! 2 solid days without any problems thought the issue was solved but then woke up this morning to it... of course didn't have logging enabled on the instance it happened to.

Feb 21, 2011 at 3:36 PM

Yeah, same thing happened to me. It seems to only be cropping up in IE 9. Combres serves up a 304 without a content-type which IE 9 won't parse at all so no css/js loads. I've spent a few hours try numerous solutions but none seem to work.

Mar 4, 2011 at 11:26 AM

Is there any news on this particular issue?

Mar 10, 2011 at 3:32 PM

We are using the latest source with orcnbeans' fix and I also updated it so the script & style tags that are output to not include the trailing /.  We have iis rewrite rules that redirect /path/ to /path for consistency.  Not sure if the 302 in there was messing with the caching but it made it harder to trace things down.  So far it has been 2 weeks without any issues.

Mar 15, 2011 at 2:43 PM

I still had problems after my initial changes so i've since removed the Response.Flush from RequestProcessor.cs (SendOutputToClient method) as I thought it may have been related to

Haven't had a problem in the last week, will know more in the coming weeks as IE9 will flat out ignore css/js if it doesn't have the right content-type sent.

Apr 11, 2011 at 4:38 PM

It happened yersteday to me, it says "text/html" instead of "text/css". i have solved restarting app.

May 6, 2011 at 4:13 PM

We are running into this issue with FF 4 and IE 9 as well....has anyone come up with a reliable solution to this?

May 6, 2011 at 5:49 PM
dplaskon wrote:

We are running into this issue with FF 4 and IE 9 as well....has anyone come up with a reliable solution to this?

Right now we dont have a reliable solution, but exist a workaround that is sufficient considering that this issue appears randomly sometimes, once a week or once a month.

The workaround consist in restart the application (the most common method is replacing again the dll's, this ensures that are exactly correct dlls and them are re-cached in memory)

I couldn't find any clue yet while code examination about this problem, but you can try also.

May 6, 2011 at 6:19 PM
Edited May 6, 2011 at 6:26 PM

Perhaps I'm missing something, but it would appear that the section that was setting the contenttype in the constructor has been reverted in the latest version of RequestProcessor...was this intentional? If not, perhaps this is the problem?


Edit: I was mistaken on this point - apologies for posting before verifying :p

May 6, 2011 at 11:40 PM

Update: I've been in touche with orcnbeans and he suggests that removing the Response.Flush iin RequestProcessor appears to have fixed the issue - perhaps this change could be applied in the trunk as well?

May 8, 2011 at 7:05 AM

Thanks for your investigating, dplaskon.  What I don't understand is that the Connect issue mentions that the content-type header is removed when no content-length is specified.  However, Combres does specify content-length right before Flush(), so I thought this issue shouldn't apply.  Anyway, I'll modify the main branch.  If anyone using the latest code (with the new change) doesn't face this issue anymore, I'll push it to Nuget.

May 8, 2011 at 11:58 AM


I've pushed this change to production, and with the frequency of the issue we were seeing (a matter of days, not weeks or months as mentioned in some posts above), I can't imagine it'll be long until we know if this worked or not.

Thanks again for an AMAZING project - combres rocks!

May 15, 2011 at 11:59 AM

Any news on when this is going to be released?

May 16, 2011 at 1:08 PM

Over a week now and we have not seen a reoccurence of this; hopefully others can confirm?

May 20, 2011 at 12:39 PM

Have this problem on a large project, 30+ StyleSheets and 30+ js files. Can anyone confirm if this has been fixed in a release yet, I see release 2.2 is available for download. We are using 2.1 and we resolve this issue as it occurs with a restart of the IIS application pool. Obviously not ideal. Would appreciate any feedback.

May 20, 2011 at 12:46 PM


You'll need to compile the trunk version for the time being (I'm not sure when Buu is going to do an official release with the latest changes in place) - this has completely resolved the issue for me.

May 23, 2011 at 11:20 AM

We run combres on a fairly busy site (> 750k pageview/month) and have run into this issue too a lot of times.

The latest trunk fixed this for us 100%.

May 25, 2011 at 8:34 PM

I am joining in the call for a push to nuget. I am having this same problem.

May 26, 2011 at 1:01 AM

+1 for this - a new stable build should be released that includes this fix.

May 26, 2011 at 12:25 PM

Hi all, I'll push a Nuget release this weekend.  Thanks for reporting that the issue was fixed with the change.

May 29, 2011 at 7:02 AM

Hello all: the change should now be in NuGet (Combres

May 31, 2011 at 2:54 AM

I have updated to 2.2.19 and now my CSS file won't load into the html of my page at all. When I view source there is no link tag to the css file. Nothing was changed in my code. All I did was update Combres from Nuget.

May 31, 2011 at 12:20 PM

Can you post the piece of code calling to Combres?  Any error/strange issue found in the log?

May 31, 2011 at 1:37 PM

My apologies, I'd managed to add an extra character in the code that was messing with it. All working now.

Jun 1, 2011 at 6:36 PM

What was the purpose of the call to Flush to begin with? Could its removal cause problems elsewhere?

Jul 14, 2011 at 9:21 AM

I haven't seen any problem.  The inclusion of Flush() in the first place was due to my paranoid, that's all :).

Aug 15, 2011 at 11:30 AM

Since last week, this issue has started appearing again...

It's reallt frustrating. Only happens in IE and FireFox.

The only fix for now is to edit one of the css files and save.

Anyone with the same issues ?


Aug 15, 2011 at 6:53 PM

I had the issues (only after public launch, annoyingly), recompiled latest from source (with latest dotLess), and it seems to have been fixed for a week or so, but it is broken again. Note, this has only been a problem in IE 9 - it works in all Fx versions I've tried.

Since it's intermittent, could public caching be causing the problem?

I'll do anything I can to help - I now have several sites relying on combres. At this point I could stand to disable caching completely if it would keep my site from breaking, at least until there's a sure fix.

Aug 16, 2011 at 3:28 PM

@Jerph: can the issue be reproducible in a particular piece of code (e.g. a particular resource set requested by IE) or does it happen randomly?  If it's reproducible, I appreciate if you could send me enough source code/settings to reproduce it in my machine.  If not, can you send over a log file's segment which contains the occurrence (so that I know which scenarios, e.g. non-modified return, server side cache, newly constructed content... might have caused this?  Any information that helps me to either reproduce or know what could be the root cause will help.  Or you could take a look at the class RequestProcessor and try to make change to see if anything works.  If there's any error regarding content-type of the combined resource set, that is likely the only class which could cause the error.

Aug 16, 2011 at 8:42 PM

It is random - boy do I wish it were reproducible. For instance, it went a week fine and then broke yesterday. I pushed out a small change, it worked for a few minutes and then broke again. I can say that if one person sees it, everyone else sees it too. I can also say that it ALWAYS works when I set "Always refresh from server" in developer tools, at least in my case.

I've created a file with some captures from Fiddler, but I don't see any difference in the headers between the working 304 and the broken 304. I created an issue and attached them for science. Maybe we can continue there?

Aug 19, 2011 at 5:14 PM
Edited Aug 19, 2011 at 5:16 PM

I can also confirm the occurrence of this bug. And, as for the others, it disappeared after restarting the application pool. I am not sure if it helps, but the problem occurred in all CSS and JS files and does not seem to be related to dotless (we are only using dotless from the command line).

This occurred on a high-traffic SaaS website and basically meant that for about 12 hours was not serving pages correctly to IE browsers which did not have the css / javascript files in their cache. It's by far the biggest bug we ever had in our product and caused us a lot of headache. While Combres is a great library feature-wise, this bug seriously makes me reconsider using it, so I am now looking for alternatives.

Aug 22, 2011 at 2:15 PM
Edited Aug 22, 2011 at 2:20 PM


If you want to have a look at a live application having this error, we just ran into it on our test instance: (live @

Please tell me if you need anything else.

I won't 'fix' our test instance for now, so you can have a look.

EDIT: OK Disregard above.... It went away again... 

this is really driving me nuts. Prio 1: remove Combres from all production sites...

Remco Ros

Aug 23, 2011 at 2:17 PM

@remcoros: I would be very frustrated if I were you too.  Quick question: you're using the latest version of Combres right?

I'll look into this issue again as soon as I could although I can't promise anything.  This has been a pain to me too because I can't see it in my environment while obviously it's causing trouble to some users.  Any help from anyone, e.g. hint on what might go wrong, sample project showing the problem, patch etc. would be much appreciated.  Also, please make sure that you all use the latest code (or from NuGet) to avoid we are all in the same page.

Aug 24, 2011 at 11:07 AM

Not sure if this info is any help, but I had this issue on one single site twice within less than 96 hours. So either this is a stupid conincidence or the problem seems to occur pretty often once it starts occurring. 

Sep 27, 2011 at 3:02 PM

Running into this issue today again.

Not once, but almost continuesly now. I change the css a bit, everything seems ok then. Then a few minutes later, the css request gets a content-type header of 'text/html' (and also a tiny different cache max-age)

I read most of the important Combres source like 10 times now and am 99.9% sure that it has nothing to do with the way Combres works.

When the issue happens, using fiddler I see a different number for 'max-age' on the combres.axd for the css.
very weird too: I have set max-age to 30 days = 2592000, but when the issue happens, It becomes something like 29.98 days (2591764 or something, but this value changes each request).

This (and the fact Content-Type isn't set) led me to the conclusion it doesn't hit RequestProcesser (so... it doesn't hit Combres route/handler).

This also (almost) led me to the conclusion that it is not Combres. So I went investigate further: disabled IIS output caching and kernel caching. Disabled all static caching. disabled IIS compression, etc, etc.
Nothing worked. 

BUT!!, when I disable combress (debug = true) everything works again.


There is some component that screwes up the request (it never hits the combres handler). This is probably an internal IIS / ASP.Net component, because I ruled out every other Http module/handler we use.

I checked IIS global config / application host / local config, etc. etc. but still can't find a thing.


For now, we are running debug mode on production.

Dec 13, 2011 at 1:08 PM
Edited Dec 14, 2011 at 11:43 AM

I had a similar issue with IE9.

I could solve it by removing the trailing slash from the Combres UrlPattern ("{0}/{1}/{2}/" to "{0}/{1}/{2}".)
It is located in /API/WebExtension.cs line 42.

If anybody can explain why the trailing slash is required?

Edit: ignore me, the problem appeared again.

Jun 29, 2012 at 5:42 PM

I don't have anything original to contribute to the discussion, but we are experiencing the same problem with a relatively recent build of Combres ( that I merged back in February 2012.

You might be able to catch it here: 

We're using it on several sites, but only one has the problem described. If we make any interesting discoveries I'll post an update.  

I'm happy to post the HTTP headers or additional debugging info.

Jun 30, 2012 at 8:53 PM

Please do post as much as details which will assist in fixing this glitch.

Aug 6, 2012 at 12:10 AM
Edited Aug 6, 2012 at 11:29 PM

I am a senior developer working for a company that has a quite complex web application and I suggested they use combres since I have used it before. I was unaware of this problem when I made that suggestion and, suffice to say; if I had been aware of it then I would surely have not suggested using combres. Now we have run headlong into this glitch which has made the product unusable until I turned combres off.

However, it was not intentional and bugs are inevitable. So, let us fix this problem as quickly as we can. I have an instance of a VM where I can reliably reproduce this problem, I also have the latest combres source so I can intake suggestions, build, and deploy to test them. If I cannot fix this quickly, then I have no option but to abandon combres in this, and all other future projects.

I have subscribed to this thread too, so if you need me to reproduce diagnostics then just ask here.

Aug 6, 2012 at 11:09 AM

@CTRSoftworks I think there's a lot of things you can help, e.g. if you could debug the source and troubleshoot the issue, great. If you could write a reliable failing test case and send me, great. Any suggestion on what might cause the issue so that I can look at, great. Or if you could share the VM or instruction to build the same VM, e.g. OS, IIS etc.

Aug 6, 2012 at 11:37 PM

Thanks Buu. First off, I apologise for the unnecessary commend about damage to my reputation in my post. It was merely pointless emoting and I have removed it. Combres is a good piece of software, which is why I use and recommend it to others.

I cannot give others the VM as it contains our software and data. However, I will try to get a cut-down solution that can be debugged so I can get to the source of the problem. I also have some hunches that I will try out.

Aug 11, 2012 at 11:58 PM

@CTRSoftworks: no worry, I can understand the frustration.  This glitch is driving me nut. Any help in addressing this is much appreciated.

Aug 12, 2012 at 1:20 AM

@All: if you can reproduce this bug, can you try to make this change in the latest Combres source and observe the effect:

Change line 163 of RequestProcessor.cs to: cache.SetCacheability(HttpCacheability.ServerAndPrivate);

This is based on remcoros' research that some thing external to Combres might cause the issue; and since he has tried a bunch of things with ASP.NET and IIS, my guess is that some proxy server somewhere causes the issue.  This change turns off proxy caching via the cache-control header.

Can anyone try and report their observation?  Also, I'm interested in learning whether this change works well with CDN or it will make CDN not ever cache a response.

Aug 12, 2012 at 1:24 AM

@remcoros: can you send me the Fiddler response (headers, content...) of a failed request? I'd love to look at it.

@swissjohn: I must be very unlucky, I've been looking at your site, F5 and Ctrl-F5 for hours hopefully seeing the issue but every response comes back with the correct content-type. How frequently does the issue occur on this particular site?

Aug 17, 2012 at 8:24 AM

The problem has disappeared by removing the Response.Flush(). I think this fix is already in the latest version.

Aug 18, 2012 at 8:04 PM

@swissjohn: thanks for updating. I thought so too. That fix was in the code since May 2011 and included in Combres 2.2.2 since Aug 2011; yet a couple of people (including you if I'm correct in the post @ Dec 14 2011) still report the issue. It either means those reporting it used an even earlier version or there are some other things causing the issue to happen to some people.

Aug 21, 2012 at 2:13 PM

I'm a little bit confused here, am I to understand that this is fixed if you just get the Nuget-package that I see now is currently at version as opposed to downloading it from here where you get the version? If so, it's probably a good reason to remove the download on this site completely since a lot of people obviously appear to be running it thinking it's the latest version, me included. I know that the site says it's supposed to be updated from Nuget from now on but when you get the source - also from here - you get what appears to be so it's not difficult to draw the incorrect conclusion that this IS the latest version. Is this site the correct source repository?

 I'd just love it if it turns out that this actually IS fixed already since my only other option is to replace combres completely and I really don't want to do that.

Aug 29, 2012 at 6:43 PM

@jantila: what do you mean by "but when you get the source - also from here - you get what appears to be"? the source is always the latest source, even latest than the 

Aug 30, 2012 at 8:18 AM

It's a bit weird. The assemblyinfo.cs for the main combres project says and the requestprocessor.cs doesn't seem to match the line numbering for the fixes you've mentioned above in this thread. I downloaded the zipfile that seems to be the latest as far as i can determine (the download link on the page ) so i haven't used mercurial to download it. Anyway, I updated one of my sites via nuget and so far, we haven't seen this issue again. I have two more sites I need to update and I've actually already tried to this for them too but so far I've had a lot of problems with getting Less to work after updating so I've had to revert back to the old one. This is a topic for another thread though.

Btw, thanks for the support and for an awesome tool! 

Aug 31, 2012 at 5:56 PM

Ok, I got it. The CodePlex source link doesn't point to the real latest (still try to figure out why), instead it points to a release in Jan 2011, before the fix was made. That's why many people building from source still face the issue. Either download via NuGet or build from the "real" latest source ( should fix the issue.

I will delete all binary downloads from Combres as well as fix this wrong latest code pointer.  

So bottom line: if anyone still has this issue, please upgrade to latest via NuGet or download code from and build it.