views:

1599

answers:

5

My question is simple (although the answer will most likely not be): I'm trying to decide how to implement a server side upload handler in C# / ASP.NET.

I've used both HttpModules (IHttpModule interface) and HttpHandlers (IHttpHandler interface) and it occurs to me that I could implement this using either mechanism. It also occurs to me that I don't understand the differences between the two.

So my question is this: In what cases would I choose to use IHttpHandler instead of IHttpModule (and vice/versa)?

Is one executed much higher in the pipeline? Is one much easier to configure in certain situations? Does one not work well with medium security?

+6  A: 

As stated here, HttpModules are simple classes that can plug themselves into the request processing pipeline, whereas HttpHandlers differ from HttpModules not only because of their positions in the request processing pipeline, but also because they must be mapped to a specific file extensions.

Kirtan
you don't need to map a handler to an extension if in a HttpModule you explicitly resolve to a class that implements iHttpHandler
rizzle
@rizzle: what do you mean "explicitly resolve to a class that implements IHttpHandler"? Do you mean the IHttpModule is also an IHttpHandler?
Ryan Riley
@Ryan: In the module you can attach a method to the HttpApplication.BeginRequest event and give it the handler that you choose, regardless of file extension
rizzle
+5  A: 

IHttpModule gives you much more control, you can basically control all of the traffic directed to your Web application. IHttpHandler gives you less control (the traffic is filtered before it reaches your handler), but if this is sufficient for your needs, then I see no reason to use the IHttpModule.

Anyway, it's probably best to have your custom logic in a separate class, and then just use this class from either IHttpModule or IHttpHandler. This way you don't really have to worry about choosing one or the other. In fact, you could create an extra class which implements both IHttpHandler and IHttpModule and then decide what to use by setting it in Web.config.

Igor Brejc
+2  A: 

Modules are intended to handle events raised by the application before and after the request is actually processed by the handler. Handlers, on the other hand, aren't given the opportunity to subscribe to any application events and, instead, simply get their ProcessRequest method invoked in order to the "main" work of processing a specific request.

Take a look at this documentation from Microsoft (about half way down the page in the "The request is processed by the HttpApplication pipeline" section):

http://msdn.microsoft.com/en-us/library/bb470252.aspx

You can see in step 15 where the handler gets its chance to execute. All of the events before and after that step are available for interception by modules, but not handlers.

Depending on what specific features you're trying to achieve, you could use either a handler or a module to implement an upload handler. You might even end up using both.

Something to consider might to use an upload handler that's already written.

Here's a free and open source one:

http://www.brettle.com/neatupload

Here's a commercial one:

http://krystalware.com/Products/SlickUpload/

If you look at the documentation for NeatUpload, you'll see that it requires you to configure a module.

Jason Diamond
+3  A: 

15 seconds has a nice small tutorial giving practical example

YordanGeorgiev
+5  A: 

An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint") that runs in response to a request made to an ASP.NET Web application. The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler. You can create your own HTTP handlers that render custom output to the browser.

An HTTP module is an assembly that is called on every request that is made to your application. HTTP modules are called as part of the ASP.NET request pipeline and have access to life-cycle events throughout the request. HTTP modules let you examine incoming and outgoing requests and take action based on the request.

Typical uses for custom HTTP handlers include the following:

  • RSS feeds To create an RSS feed for a Web site, you can create a handler that emits RSS-formatted XML. You can then bind a file name extension such as .rss to the custom handler. When users send a request to your site that ends in .rss, ASP.NET calls your handler to process the request.
  • Image server If you want a Web application to serve images in a variety of sizes, you can write a custom handler to resize images and then send them to the user as the handler's response.

Typical uses for HTTP modules include the following:

  • Security Because you can examine incoming requests, an HTTP module can perform custom authentication or other security checks before the requested page, XML Web service, or handler is called. In Internet Information Services (IIS) 7.0 running in Integrated mode, you can extend forms authentication to all content types in an application.
  • Statistics and logging Because HTTP modules are called on every request, you can gather request statistics and log information in a centralized module, instead of in individual pages.
  • Custom headers or footers Because you can modify the outgoing response, you can insert content such as custom header information into every page or XML Web service response.

From: http://msdn.microsoft.com/en-us/library/bb398986.aspx

Ramani Sandeep