[Announcement] Falling through to IIS now requires opt-in

[Tratcher]

A change has been made to the IIS ASP.NET 5 server (Microsoft.AspNet.Server.IIS) such that applications must opt into IIS fallback. Previously when a request reached the end of the managed pipeline without being handled it would automatically unwind the managed pipeline and fall back to IIS. Now the end of the managed pipeline will return an empty 404 response like on other servers. To opt into the fall-through use the new extension app.RunIISPipeline(); at the end of your managed pipeline. This extension will no-op on non-IIS servers.

The primary impact is for static files. Before there was significant confusion on if requests were being handled by the managed static file ASP.NET middleware or the native static file IIS module. Now IIS will not try to serve static files without the opt-in extension. Alternatively applications can use the app.UseStaticFiles() or app.UseFileServer() extensions to use the managed static file middleware.

[dmccaffery]

Just out of curiosity, is there any performance impact of relying on the static file middleware VS IIS? I'm sure its minimal -- just wondering if there is any data out there that would serve as a "best practice" metric.

[Tratcher]

There's probably some impact, but we haven't done a direct comparison yet.

A few perf notes:
A) ASP.NET 5 runs with the equivalent of RAMFAR so it observes all requests. Static files are not exempt.
B) You control the managed pipeline order so you can put the static file middleware early in your pipeline and short circuit potentially more expensive operations.
C) The middleware only processes the headers, it uses the same API as the native module to send the body in kernel mode.

[Daniel15]

Is there a way to configure IIS such that it serves static files itself without ever hitting the managed pipeline? I do that on Linux in my Nginx config and it works quite well.

[Eilon]

@Daniel15 for performance it is common to put static files on a different site with a different domain to prevent things like cookies from being shuttled back and forth, and to allow more simultaneous open connections for parallelization (not as big an issue with HTTP 1.1 though).

[Tratcher]

@Daniel15 No, I haven't seen a way to bypass ASP.NET 5 for static files. In IIS's handler mappings you could try changing StaticFile's wildcard * to specific extensions and moving it higher in the list.

[Daniel15]

Good point @Eilon.

I don't use IIS much and this is trivial to do on Nginx so I thought it'd be easy on IIS too. I guess IIS doesn't have an equivalent to Nginx's try_files.

[dmccaffery]

That's what I usually do; host static files on static.domain.com or some equivalent; I was just curious for curiosities sake. By the time you start looking at static file handling without the managed pipeline as a means to improve performance, you would already have an enormous amount of traffic and enough reason to look into CDNs and the like. I didn't mean to imply that we should care about the subtleties as an issue -- it's very likely to be premature optimization no matter how you slice it.

[Eilon]

BTW even static.domain.com likely isn't getting max perf because cookies might still be sent by the browser if it has cookies from domain.com. But, as was mentioned, the odds of this mattering for most sites is low.

[dmccaffery]

Yup; it was just an example; always use a different domain, no reason to auth or process cookies, and can set cache headers statically, etc. (depending on whether or not the resources are likely to ever change).

[dmccaffery]

Also, and not to beat a dead horse, you can canonicalize your URL to www.domain.com and set your cookies using www.domain.com, then use a subdomain like static.domain.com. Or at least I think that works. O.o

[CoskunSunali]

@Tratcher is the change intended to fix the issue we discusses at aspnet/StaticFiles#65?

[Tratcher]

@csunali No, that's unrelated. runAllManagedModulesForAllRequests is the only way we can address that issue due to how we're loaded. We'll add it to the templates and during publish: aspnet/dnx#2484

There's a long term solution that changes how we get loaded, but that will require writing a whole new bootstrapping system.

[CoskunSunali]

@Tratcher, thank you for the details.

[Tratcher]

This became obsolete in beta8 due to #364