Changes I have made in Contrib.Cache

Topics: Troubleshooting
Jul 20, 2013 at 12:31 AM
Three months ago, with Contrib.Cache module, I have seen that when clicking quickly and repeatedly, I got some http 500 errors. An exception was thrown in response.Flush() in OnResultExecuted() in OutputCacheFilter.cs. With try / catch blocks I could capture a message that effectively said that remote host has closed the connexion (error code 0x80070040). So, to prevent these http 500 errors, I have used try catch blocks around response.Flush():
try { response.Flush(); } catch { return; }
In another context with session variables, I also had this exception: “Session state has created a session id, but cannot save it because the response was already flushed by the application.”. I know that you can disable caching with some url, but I still had a case with this exception. To fix it, at the beginning of the OnResultExecuted() function in OutputCacheFilter.cs, I have added these 2 lines:
// do not response.Flush() if new session with data to be saved
var session = filterContext.HttpContext.Session;
if (session.IsNewSession && session.Count > 0) return;
Finaly, about a problem with RequestVerificationToken in custom forms, I have modified OutputCacheFilter.cs file as described in this thread:
http://orchard.codeplex.com/discussions/429615

Thanks
Coordinator
Jul 22, 2013 at 9:19 PM
Thanks, but this is not the best place to report that. Can you please file a bug with those findings?
Jul 23, 2013 at 1:48 AM
Ok. Thanks. I will do it. But, after reading Orchard.OutputCache in Orchard 1.7 and new tests, I need your advice before

Point 1: I can reproduce it on my local server with WebMatrix, even with this condition as in the last OutputCacheFilter.cs: If (response.IsClientConnected) response.Flush(). But, today I test it on my production server and I can't repro it. So, do you think it's relevant to file a bug for this point even if I can repro it only on my local server ?

Point 2: Do you think it's always a mistake to have caching and session variables ? Or, is it a case we have to consider ?

Point 3: I read again the thread I have mentioned, this issue depend on another modification where the goal is to use AntiForgeryToken even with Unauthenticated user. So, it is not a concern for me and I can forgot this point

Thanks