That used to be the case - but when asp.net 4.0 integrated mode came into being things moved around a lot.

• If runAllManagedModulesForAllRequests="true", all modules - regardless of their preCondition attribute setting fire on all requests. This also true for Application_XXXX events implement on the HttpApplication

See basically - in this new integrated mode - a call to myimage.jpeg - could actually be served by a httpmodule - and there are quite a number of sites and places where this sort of thing is the case.   

Take a image hosting site that wants to ensure every image on their site it watermarked and timestamped.  Because the handlers CAN be set to fire for every type of event - it is possible to tell a handler in its preconditions to fire for ALL REQUESTS - intercept the request before it gets to the normal IIS image load layer - load the image internally- watermark it on the fly - and hand the watermarked and timestamped or whatever image onto the requesting browser.

By default handlers ONLY fire when their preconditions parameters are set - each httpmodule declares a set of preconditions for when it is run.  As a rule - most managed modules are set by default with a precondition=managedHandler - this tells the module to work like you work expect - and to ONLY run for requests that are routed to managed requests - such as a aspx page or asmx stream.

However - what  runAllManagedModulesForAllRequests=true does in not exactly what people expect - it does not just turn on a switch to tell all modules to fire for managedRequests --- what it really does is change the default precondition to "" for every module -  which in effect tells all the modules to fire for EVERY request sent to the host.  And EVERY means EVERY - anything that hits the server from a txt file to a jpg to a wmv.

So what is the real issue behind all this issue showing up on MOST dnn systems --  it has a lot to do with extensionless requests -- this issue started to crop into DNN when the advanced url system was created - BECAUSE it allows the use of page requests that dont have an aspx extension.

For such extensionless requests to work and be redirected to the right places inside IIS - requests need to be handled and processed before iis gets hold of them internally - there was a bug in how IIS handled this that meant extensionless requests were being passed to IIS instead of the right handlers.

And its the reason why the service patch mentioned in a previous post fixes the issue it almost every case - its a patch that changed how extensionless requests are handled.

Westa