IIS and .NET | Tech Off

stevo_
Human after all

Anyone ever looked into the core of how IIS and .NET work to accomplish 'ASP.NET'? I have, and all I can say is.. what has been seen- cannot be unseen..

But it got me wondering, what the performance would be like if you built a custom isapi extension, and request thread pool, and dispatched to a .net runtime slave pretty early on the request, and the core handling in .net was really basic, no authentication systems or anything involved (HttpApplication and HttpContext do so many things that are just not required).

And then built abstractions on top of this in .NET to get authentication and whatever.

I'd be really interested to know if anyone had done anything like this, essentially a full replacement to asp.net- where the goals are to be lightweight, .net, and the purest execution not based on file handlers, but an application object singleton (per app) to handle requests (from this you could abstract request agents to forefill requests, and on these you could build handler like systems).

Of course I don't think this would hit the masses, theres plenty of reasons why, one key aspect related to getting an isapi extension installed in shared environments.

This is purely out of interest, not for commercial reasons.

Dexter

I'm not sure I understand what you are asking. Isn't ASP.NET an isapi extension after all? And as far as I know it uses the thread pool or something similar that reuses threads. As for authentication isn't that optional anyway?

stevo_
Human after all

Of course asp.net is based on an isapi extension, the extension dispatches to a thread pool, and authentication is optional, but that doesn't mean that theres not a huge amount of work going on (especially once you've crossed into the managed world), that happens just because something 'might' be needed, also asp.net is old, and based upon requirements that classic asp gave, its not modern, and bringing modern paradigms to asp.net (such as routing and the mvc) requires doing additional work.

My entire point is about creating an entirely new web context for .net, completely different to asp.net, based on modern requirements, and abstractions in the managed space, so that you could (if you wanted), go back to something so basic as the managed equiv of an isapi filter / extension.

This is purely based on interest, not as a production solution- and about the possibility of making a lightweight .net web orientated execution env.. vs. asp.net which is a somewhat monolithic stack.

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to stevo_

#Apr 15th @ 5:22 AM

Actually, in IIS7 ASP.NET is not an ISAPI extension anymore, managed handlers are built into it. All you need to bypass all the ASP.NET stuff is to write a http handler or module in .Net and register it with IIS7.

stevo_
Human after all

In reply to Sven Groot

#Apr 15th @ 5:27 AM

I'm not entirely sure how iis7 ties into .net, I know this is true, but to what degree I can't say- this is one of my concerns however because whilst you say I can bypass all of asp.net, IHttpHandler is still based on the asp.net infrastructure, it takes HttpContext (which is linked to the HttpApplication).. the HttpContext and HttpApplication are actually the big offenders in my eyes, I can today write a http handler or module to bypass 'Page' for example, but I still only run after plenty of work happens in the HttpApplication/HttpContext.

Again I'm not sure how exactly ii7 works with the managed runtime, for example- I assume the managed runtime handlers and httpapplication aren't involved in requests handled by isapi extensions / filters.. but from what I can assume is- rather than aspnet_isapi handling asp.net requests, iis7's native request handler (for what would be static resources otherwise), processes in context of asp.net.

In which case, these aren't so much managed handlers in iis7, just that iis7 implicitely ties to .net now instead of via an isapi extension.

Dexter

In reply to stevo_

#Apr 15th @ 5:42 AM

An IIS7 "module" is roughly the equivalent of an isapi extension but the managed variant of the module innterface still uses the HttpApplication object. I guess at this point it can be said that some "core" parts of ASP.NET like HttpApplication and HttpContext have become part of the web server itself.

Sure, you can write an unmanaged module, host the .NET runtime yourself, write code to parse and handle the requests and so on. That will be a ton of work and when it's all done you may discover that you reinvented at least some parts of HttpApplication & co.

For example HttpContext offers access to a HttpRequest object which in turn handles parsing of POSTed forms. Are you sure you want to reimplement all that (any many other basic http features) just because some other features offered by HttpContext are not widely used?

stevo_
Human after all

I'd certainly be interested in trying in any spare time, but I was interested if anyone knew of anything.. the thing is, with iis7 - you can register native modules (isapi is considered a native module - so this is pretty low), and you can register managed modules (ihttpmodule's), theres a drastic difference between these two..

I just wonder why the IIS team didn't make the managed part of 7's support at a much lower level, and abstracted asp.net on top of that.. this way they could have enabled developers to write managed code that works at a lower level, and could enable a lot of innovation and research.

Dexter

In reply to stevo_

#Apr 15th @ 6:17 AM

If you want to try something like that then you should take a look at HttpListener (http://msdn.microsoft.com/en-us/library/system.net.httplistener.aspx).

This is not IIS but for a start it will likely be easier compared to writing an unmanaged IIS module and hosting the .NET runtime yourself.

staceyw
Before C# there was darkness...

In reply to stevo_

#Apr 15th @ 6:17 AM

"I just wonder why the IIS team didn't make the managed part of 7's support at a much lower level, and abstracted asp.net on top of that.. this way they could have enabled developers to write managed code that works at a lower level, and could enable a lot of innovation and research."

Not sure what your asking here. You can plug in anywhere in IIS7. Not sure how much deeper you can get without just writting your own http server.

http://weblogs.asp.net/scottgu/archive/2007/04/02/iis-7-0.aspx
"You can now write code anywhere within the lifetime of any HTTP request by registering an HTTP Extensibility Module with the web-server. These extensibility modules can be written using either native C++ code or .NET managed code (you can use the existing ASP.NET System.Web.IHttpModule interface to implement this).

All "built-in" IIS7 functionality (authentication, authorization, static file serving, directory listing support, classic ASP, logging, etc) is now implemented using this public modular pipeline API. This means you can optionally remove any of these IIS7 "built-in" features and replace/extend them with your own implementation."

ASP.NET on IIS 7.0 has itself been changed from being implemented as an ISAPI to instead plug in directly as modules within the IIS7 pipeline:

stevo_
Human after all

Staceyw, the whole point is that IHttpModule is a huge abstraction compared to the native c++ modules.. the IHttpModule in .NET world is ASP.NET, which has pretty significant work to do to 'arrange' itself around requests.

What I was asking for, and would be willing to prototype, was the pure managed equiv of what the native modules look like (a hell of a lot more lightweight).