locked
ProcessRequest in Handler.ashx RRS feed

  • Question

  • User-384212680 posted
    How does the ProcessRequest function in Handler.ashx get called?
    Wednesday, May 17, 2006 2:34 AM

All replies

  • User-1029435529 posted

    When any request comes into an ASP.NET website, it is assigned an HttpApplication object.  This object loads up any IHttpModules that are required (such as the FormsAuthentication module), and finds a single IHttpHandler that must ultimately handle the request.  Typically, it is an .aspx page that is the IHttpHandler used to handle the request.  Othertimes, it is an .ashx file that is the IHttpHandler used to handle the request.  No matter which IHttpHandler is used, it is the HttpApplication object that calls its ProcessRequest method.

    That is a very brief overview.  If you'd like to learn more, you can start with the ASP.NET Application Life Cycle Overview.
     

    Wednesday, May 17, 2006 3:51 AM
  • User-384212680 posted

    Thanks  for your help, SomeNewKid.  This is how I now see it.

    When the application object constructs the default.apsx page, the IHttpHandler for aspx filetypes is used.  During aspx page construction, certain img controls whose src is Handle.ashx are created. When those img controls are created, the application object uses an IHttpHandler, in this case Handle, for ashx files to call the ProcessRequest Method. 

    Wednesday, May 17, 2006 6:54 PM
  • User-1029435529 posted

    You're on the right track, but that's not how it works.  (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.
     

    Wednesday, May 17, 2006 7:59 PM
  • User-384212680 posted
    Your story was not only a little easier to understand but a lot more informative than the two books I have that described the Application Life Cycle and the Page Life Cycle.  I never realized that there were separate and distinct trips to the server for each of the IIS recognized file types referenced in aspx.
    Thursday, May 18, 2006 1:41 PM
  • User640203735 posted

    This is an excellent metaphor to explain the application life cycle. Great Job.  Keep up. Hope others are explain the difficult and confusing concepts as clearly and concisely like you.

    Monday, April 14, 2008 9:00 AM
  • User-449449542 posted

    Thank you friend , the easiest explanation i have got ,and very easy to remeber also by that manager- worker example.

    Friday, September 30, 2016 7:29 AM