CassetteHttpModule breaking WebResource.axd and possibly ScriptResource.axd

[nazjunaid]

We have a MVC website which uses N2 CMS which is a webforms based content management system with a nested admin interface that sits in your application.

Since adding cassete it has broken the WebResource.axd requests which started to return empty content.

I've fixed this in my fork https://github.com/nazjunaid/cassette, I wasn't sure if it should ignore all .axd requests so I just ignore requests specifically to those resources.

It might not be an elegant solution but seems to work now maybe this should be moved to an ignores section in the configuration?

Found threads with people posting similar problems with other modules

http://forums.asp.net/t/1161118.aspx/1
http://forums.asp.net/t/1017291.aspx/1

[andrewdavey]

Thanks for reporting this. I'm still working on a rewrite of Cassette, so I make sure I test for this issue in the new code.

[andrewdavey]

Cassette 0.6 uses routing instead of HttpHandlers directly, so this problem should no longer exist.

[nazjunaid]

This issue still exists and is being caused by the CassetteHttpModule which is still processing every request I have re-created the fix in my fork

[andrewdavey]

Are you able pin down where things go wrong? I assume it's something to do with the HTML output rewriting that occurs in the Response.Filter Cassette installs: https://github.com/andrewdavey/cassette/blob/master/src/Cassette.Web/PlaceholderReplacingResponseFilter.cs

I'd really like to solve this without blindly skipping all axd requests if possible. However, it's an okay solution for now since I doubt people are routing axd requests into a view page that uses Cassette.

[nazjunaid]

Sorry I have not been unable to figure out why it's happening from what I read on-line it's a common issue with HttpModule's and most posts suggest ignoring axd's which I know isn't the most elegant solution.

I'll try stepping though PlaceholderReplacingResponseFilter

[nazjunaid]

From what I can see the PlaceholderReplacingResponseFilter get added to response.Filter but the Write method of the filter method never gets called.

However if I stop the PlaceholderReplacingResponseFilter from being added to the response.Filter then it fixes the issue so I guess we could apply the fix in CassetteApplication.cs instead of the CassetteHttpModule.cs if you feel that's more elegant.

[andrewdavey]

I've been digging into this some more. Are you seeing both WebResource.axd and ScriptResource.axd failing, or just WebResource.axd? Because they have different handler classes. The WebResource.axd is handled by System.Web.Handlers.AssemblyResourceLoader. This class makes a call that disables the response filters (context.Response.IgnoreFurtherWrites();). The ScriptResourceHandler does not call this method.

So my thinking is to check if the current handler type is AssemblyResourceLoader and then not install the response filter. This seems more focused than blindly skipping all .axd requests.

[nazjunaid]

i've only seen the issue in WebResource.axd I just assumed it happens with ScriptResource.axd too, but looks like N2 CMS doesn't use ScriptResource.axd so i'm unable to fully verify if the problem exists there.

Looking at your findings I think it's probably OK checking for the AssemblyResourceLoader.

[andrewdavey]

Latest in master now checks for AssemblyResourceLoader and does not install the filter.

[nazjunaid]

Sorry to be a pain but fix doesn't appear to work I've stepped through it and it looks like httpContext.CurrentHandler is null I checked httpContext.Handler which is also returns null.

[andrewdavey]

Perhaps I'm checking the current handler too soon in the http request pipeline. I'll try attaching to a later event and test it there.

[andrewdavey]

Latest in master now attaches to PostMapRequestHandler instead of BeginRequest. So the CurrentHandler should be assigned. Can you give it a try and let me know if it's working for you? Thanks.

[nazjunaid]

Yay, It works!

The interesting thing is it the CassetteHttpModule methods doesn't even get hit any more for Webresource.axd requests so you don't need to do the check httpContext.CurrentHandler is AssemblyResourceLoader

However unrelated I had to comment out the recent commit a1a8dff as httpContext.Response.Flush(); was causing our stylesheets return really weird encoded data.

[andrewdavey]

AssemblyResourceLoader may be ending the request before the later pipeline events are raised. That seems a bit weird though. Can you confirm you weren't getting cached or 304 responses? e.g. by checking in fiddler to see what's being sent.

Yes, the flush call is doing some bad stuff for me too (breaking redirects!) I'm working on a fix now.

[nazjunaid]

Yes you are right there appears to be some caching coming into play as the first time it does hit and every other time it's cached.

[andrewdavey]

Latest in master has removed the Flush call.