Filtering is not allowed. (System.Web.HttpResponse.set_Filter)

[aburok]

From time to time, I get this error on production. I was not able to reproduce it on my local environment.
Logs are showing this error :
System.Web.HttpException (0x80004005): Filtering is not allowed.
at System.Web.HttpResponse.set_Filter(Stream value)
at ClientDependency.Core.Module.ClientDependencyModule.ExecuteFilter(HttpContextBase http, IEnumerable`1 filters)
at ClientDependency.Core.Module.ClientDependencyModule.HandleRequest(Object sender, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Source file for this is :
https://github.com/Shazwazza/ClientDependency/blob/75bfc3fbb3882921dedd6ccafefbd408e50f88e4/ClientDependency.Core/Module/ClientDependencyModule.cs

I found some information about that error :
http://stackoverflow.com/questions/23708181/filtering-is-not-allowed
moonpyk/mvcdonutcaching#20

Could you guys fix that?

[Shazwazza]

I can see what can be done, without being able to replicate makes it a bit of a guess though. On your local environment, do you have debug=false in your web.config when trying to replicate?

[aburok]

Yes, I've tried to replicate this with debug-false and Release solution configuration.
This bug is tricky because it doesn't occur always... And I cannot find any reasonably scenario that would reproduce it all of the time.
Even if you could add this fix, how long it would take to release new package on nuGet ?

[Shazwazza]

Well that's the problem, how would I know if I've even fixed it or where the problem is if I cannot replicate it? Once a fix is there it takes very little time to get it up on Nuget... if you know where the fix could/should be made please submit a PR and I can have a look. At the moment however, I don't have a whole lot of time to do trial and error testing to see if I can discover how this problem occurs but I will look into it eventually

[aburok]

No need to be nervous, I didn't meant to sound like I'm demanding something.
Your library is free and I know that. I will try to write a pull request for that.
Thank for quick answer though.

[Shazwazza]

That'd be ace, otherwise I'll see if i can figure something out when i have some time

[maarten-kieft]

I came across this issue since I had it too. After a bit more debugging I found the cause in my case.

I'm using Umbraco which includes your library. My umbraco page is build up out of smaller components. For each component we execute the umbraco function: RenderTemplate.

One of those components had a fault / bug in the view which caused an exception. However the renderTemplate method detects this, places the result in html comments and keeps rendering the rest.

However the page does give a 500 error back with the error which aburok decribes.

I could reproduce this locally. Hope it helps you guys?

[maarten-kieft]

I had this issue again and again it was caused by a different exception. So this error is basically hiding the real exception. I guess this error occurs when the user friendly error pages mechanism kicks in. The problem is is that it actually hides the real exception. Is it possible to catch this error and ignore it?

[Shazwazza]

Hi all and sorry for the delay.

Firstly i'd like to make sure you know that using RenderTemplate is generally bad practice, see https://our.umbraco.com/documentation/Reference/Common-Pitfalls/#rendertemplate

Don't get me wrong though, in some scenarios it might be required, i just want to make sure you aren't using it for things it shouldn't be used for, it is very problematic with regards to performance if misused.

There's an event you can bind to when filtering occurs https://github.com/Shazwazza/ClientDependency/blob/master/ClientDependency.Core/Module/ClientDependencyModule.cs#L17

You can cancel the filtering - if you know it definitely should be cancelled if there something specific in your request/response. Perhaps you could test this? Maybe at this stage since your page is in error that the current http response is already a 5xx response? If that is the case then you'd cancel the filter. I've not tested this yet but it might be worth trying and if that works i can add that check to CDF directly, i'm just not sure if at the stage of applying the filter you can detect if there's already an error.