Application life cycle ( ASP.NET )

I was looking for some comprehensive text about how IIS and ASP.NET handles application request and I found this post reply. I am just removing the context in which it was replied to and quoting the reply.

In the following description, I’m going to remove the Http prefix from the main objects that are used.  It should make the description easier to read.

Let’s say that Michelle visits your website, and requests your default.aspx page.  This request is received by the web server’s Internet Information Services.  IIS looks at the extension, sees that it is .aspx, and knows that this request is to be processed by ASP.NET.  So, it says to ASP.NET, “Here is a request.  You handle it, and give me the HTML that needs to go back to Michelle.”

The first thing ASP.NET does is create a Context object, which is kind of like a suitcase that holds stuff.  ASP.NET then creates a Request object that contains all the information that IIS passed to it, and puts that Request object into the Context suitcase.  ASP.NET then creates a Response object, which will hold the HTML that it must pass back to IIS, and puts that Response object into the Context suitcase.

The next thing ASP.NET does is create an Application object, which is kind of like a manager.  ASP.NET hands the Context suitcase over to the Application manager and says, “In this suitcase is the Request that we’ve received, and the Response that you need to fill out.  Go ahead and do it.”

The Application manager is like all managers, who doesn’t want to get his own hands dirty, and wants others to do the hard work.  The Application manager uses two types of workers: Module workers and Handler workers.

The Module workers are able to peek into the Context suitcase and make some decisions.  For example, the Security Module worker peeks in and looks at the user (Michelle) and looks at the page requested (default.aspx), and decides whether this is okay.  If the Security Module worker decides that this is not okay, the worker can adjust the contents of the Context suitcase (such as changing the page requested from default.apsx to login.aspx).

After the Module workers have been given the chance to peak into the Context suitcase and potentially alter its contents, the Application needs to find a Handler worker whose job it is to fill out the Response object that is sitting in the Context suitcase.

The Application manager is truly lazy, and doesn’t want to know anything about the Handler worker except that the worker can process a Context suitcase.  So, the Application manager tells a Factory worker to go and find a suitable Handler worker.  It is this Factory worker that looks at the page name (default.aspx), and “creates” a Handler worker out of the page.  The Factory worker hands over the Handler worker to the Application manager.  The Application manager gives the Context suitcase to the Handler worker and says, “Process this Context suitcase, and then give it back to me.”

The Handler worker, which was born out of the default.aspx page, then uses the Request object to decide what to do, and ultimately creates the HTML that goes into the Response object.  When that is done, the Handler worker gives the Context suitcase back to the Application manager.  The Application manager then takes the Response object, which has now been filled out, and hands the response back to IIS, which in turn sends it back to Michelle.

What Michelle receives is just the HTML for default.aspx–no images yet.

Now, the browser looks at this HTML, and sees that it contains an <img> tag, which points to your image.ashx file.  So, the browser sends a new request to IIS, asking for that image.  IIS looks at the extension, sees that it is .ashx, and says to ASP.NET, “Here is a another request.  You handle it, and give me the image that needs to go back to Michelle.”

You will see, I hope, that this is a completely new request.

So ASP.NET creates a new Context suitcase, and gives it to a new Application manager  And that Application manager goes through the whole process again.  But this time, the Factory worker returns a different Handler worker.  Whereas the Handler worker that was born from the default.aspx file created an HTML response, the new Handler worker is born from the image.ashx file and creates an image response.  But both Handler workers are simply given a Context suitcase and told to fill out the Response object inside.

The Application manager gives the Response object back to IIS, and IIS sends the image back to Michelle.

And if there is another <img> tag on the same default.aspx page, then the whole process occurs again.

So, that is where you were a little wrong.  When the default.aspx page was requested, that was not the time at which the Application manager worried about any <img> tags.  At this point, there was just a single Handler worker whose job it was to create the HTML.  It was later, during a separate request and using a new Context suitcase and a new Application manager, that the image.ashx-based Handler worker became involved and created an image.

Like any story, this one covers up certain truths. For example, IIS and ASP.NET do not talk as directly as I’ve suggested. And the Module workers can do more than peek and poke about in the Context suitcase.  Still, I hope this little story is easier to understand than reading a technically-accurate explanation of the ASP.NET life cycle.

[Huge disclaimer; this is not at all mine. Credit is due to the person who posted the reply]