For that 40 seconds, IIS and ASP.dll and x.asp and the browser are in a complex 2 way conversation.

You could test this in the real world by shutting down IIS in middle of the request say 20 seconds in and x.asp would die immediately. Or crash asp.dll or delete the file. Any one of the 3 conditions will break the script.

The technical term for this is the 3 things are "tightly coupled" a real no-no to 24 x 7 x 365 uptime. Thats why IISreset and server reboots tend to be needed - the perils of tightly coupled systems.

Its also why ASP.DLL can't run under apache or Domino or non-IIs servers it not only is tightly coupled to IIS it "borrows" the response object from IIS and Apache and domino don't have such a object to borrow.

And since x.asp y.asp or 50 other users may run x.asp concurrently as explained in:http://www.learnasp.com/advice/roundrobin.aspIf y.asp or another one of the 49 users running x.asp concurrently crashes all 3 parties (IIS, other users scripts, ASP.dll) get hosed even if only 1 users script goes haywire. Memory leaks in any one of the 3 affect all of the 3!!!!! Ouch.

You could test this in the real world by shutting down IIS in middle of the request say 20 seconds in and x.asp would die immediately. Or crash asp.dll or delete the file. Any one of the 3 conditions will break the script.

For the first millisecond or two IIS sees a request for x.aspx and then quickly hands it to ASP.net worker process and then "lets go" and disconnects.

For the next ~39 seconds IIs does not know the request for x.aspx exists. YOU COULD SHUT DOWN AND RESET IIS 20 seconds into the request and then revive it later and x.aspx could care less.

At the 40th second when the ASP.net worker process is done with x.aspx it now has n bytes of HTML that it hands back to IIS in a millisecond or two. IIS has nothing to do with the request in the "in between" 39 seconds.

As far as IIS knows someone asked for x.aspx and it gave that request to something else for 39 seconds and lets go of the request. At 40th second someone throws some finished HTML back. IIS interacts with the request for a few milliseconds not 39 seconds.

The ASPnetworker process has it own response and other objects and does not need to borrow them from IIS.

this has many implications:1. A crashed asp.dll or crashed IIS or crashed x.asp has no effect on any ASP.net scripts - NONE.2. a crashed aspx file or crashed ASP.net worker process or memory leaks cannot hurt IIS or crash it at all and cannot hurt or crash asp.dll3. If ASPnet worker process tries in 40th second to give back HTML to IIS and IIS is crashed it actually can IISreset automatically to force IIS to accept the file back. Saving a human a trip to the server to reset a hung IIS.4. If Microsoft feels like it they can easily map domino or Apache or whatever* to serve .aspx files. Any webserver on planet can handle the millisecond file drop off and being handed back static HTML.

* The Cassini project with source code contains enough hints and foundation that any experienced programmer could modify cassini to work with Apache, domino, etc. but they aint gonna come out and say it since MS wants everyone to use IIS. They can even trick NT4 or win95 PWS to serve ASP.net with small modifications to Cassini, but MS doesnt want people using ASp.net on 98 or NT4 - they want people to upgrade. But Cassini shows the backdoors to make it run anywhere.

There is more to this I will explain if asked further qestions but I have to prepare a few more emails on enter topics and get to bed.

Basically matrix just uses Cassini and skips IIS altogether. It sets up a listener for http://localhost/whatever.aspx and it can run ASP.net aspx files without even IIS on the machine. So if someone put Webmatrix + cassini on a machine it does not necessarily alter IIS at all. IIS does not know how to serve .aspx if cassini is installed only necessarily.

To ensure IIs also knows how to serve .aspx and not just Cassini/WebMatrix run:aspnet_regiis.exe from the command prompt. You can find this file in .net framework/v1.0.3705 or somesuch.