CassetteHttpModule breaking WebResource.axd and possibly ScriptResource.axd about cassette HOT 16 CLOSED

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.

from cassette.

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

from cassette.

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

from cassette.

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.

from cassette.

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

from cassette.

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.

from cassette.

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.

from cassette.

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.

from cassette.

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

from cassette.

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.

from cassette.

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.

from cassette.

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.

from cassette.

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.

from cassette.

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.

from cassette.

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.

from cassette.

Latest in master has removed the Flush call.

from cassette.