-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermittent empty bundle content with HTTP 200 response #21
Comments
We have isolated System.Web.Optimization.Less as the cause. We changed to Bundle Transformer: LESS 1.9.1 and the problem has been resolved. |
We encounter the same issue. The situation occurs randomly. |
I'm also seeing this same issue as well. After a bit of an initial investigation I have found that it seems to fail on the compilation of the less files, typically after the app pool of the application has been shutdown and then restarted. If you add a standard CSS file to the bundle it gets compiled and added to the bundle where as the Less file does not. |
I wrote an app that restarts the app pool every 10 seconds, and restarts IIS every minute, and then using ChromeDriver tries to request a very basic MVC app I wrote that uses System.Web.Optimization.Less. The plan was to leave it for an hour with ChromeDriver taking screenshots, but actually the bug happened in the first few minutes, and only fixed itself with an The error being produced on the page was:
My less files:
and foo.less:
So it looks like it's the compiler that is breaking. I'll fork it and see if I can add a compile-retries setting or similar for this bug. |
The problem seems to be from the querystring there, dotless is using it as its content. The LessCssHttpHandler alongside an extension method to generate a fingerprint based on the application version looks like the best alternative for now, particularly as LESS bundling is part of LESS itself. |
Hi, Any news on this issue? I have the same problem and don't really want to move to BundleTransformer as it depends on A LOT of other packages. Thanks! |
Ooh, @yetanotherchris, could you consider sharing the test bench and saving me the trouble? I've run into this in an environment where debugging was very hard, but having an easy repro would be a major help. I could take a swing at fixing this in dotless if you did. |
So it turns out this is actually a duplicate of #17, and it's in fact really easy to reproduce: run your site with a startup url that has a query string parameter that dotless would consider invalid. E.g. ?a=b-c. If the very first request both hits a page that triggers LESS bundle generation and contains query string variables that dotless can't deal with, this happens. I'll add some further thoughts to dotless/dotless#418 where they belong. |
Could you please try to upgrade to the latest dotless release and see if that fixes the issue for you? |
I'll try do do this ASAP. Thanks! |
Please try the latest release. Thanks! |
Hi guys. I apologize in advance for the vagueness of this issue.
We have two sites using the latest version (1.3.2) deployed in production (not debug). The content of the less bundles is fine but occasionally (we're not sure of cause) the bundle content will be empty (returns with a 200 response) and the v parameter is empty: "skin?v=" so no hash value. I've poked around in your source and the System.Web.Optimization source and am at a loss as to how this could occur. I had thought it could be related to cache items being cleared (possibly due to low memory) but I think it unlikely.
If the cause was due to a less transform failing, I would expect it to always fail. The production sites are fine for long periods of time but then occasionally fail with this problem - a subsequent app pool recycle fixes it.
We think the timing correlates to when we upgraded from version 1.2.3. Have you encountered any similar reports? The frustrating thing is I can't reproduce this problem in any environments other than production so it's making trouble shooting really difficult. No exceptions are logged. I'm contemplating reverting back to version 1.2.3 but would prefer not to.
The text was updated successfully, but these errors were encountered: