HTTPHandler vs .aspx

Question

What are the advantages of using an HTTPHandler vs an .aspx? Does it have the same capabilities and is it lighter weight and faster?

What are some of the disadvantages?

Answer 1

Aspx uses full power Web form with complex page life cycle and a lot of additional processing. HttpHandler is pure and lightweight. It has only functionality you implement.

Answer 2

By .aspx you really mean an instance of System.Web.UI.Page which as you can see in the meta-information for that class is an implementation of IHttpHandler - in other words (roughly speaking) a Page instance is an HttpHandler (this is rather the point) plus a whole bunch of stuff which gives it Page behaviour.

The difference therefore, is that using Page you can leverage all of the things it gives you (viewstate, control-ness, a life cycle, etc..) at the cost of having to have all of that overhead regardless of whther you need it or not, vs writing your own implementation where you can make it as lightweight and fit for purpose as you choose at the cost of having to write it all yourself.

HttpHandler is therefore particularly appropriate when you're not interested in Page support because you aren't delivering a semantic page response - it is almost certainly a mistake to deliver XML, JSON, images, or anything but HTML style mark-up with a Page.

In practice, I choose a third option - MVC - most of the time :)

Answer 3

Remember that when your .aspx page is compiled, it will be turned into a class that derives from System.Web.UI.Page whether directly or indirectly (by inheritting from a "code-behind" class that in turn is either directly or indirectly inheritted from Page.

Page implements IHttpHandler, so you're never not using IHttpHandler.

And a quick scan at the member list of Page gives its own good answer to this question. There's a lot going on, and a lot offered to deriving classes (that is, to .aspx files and to code behinds). And that's before we consider the way .aspx files are parsed to make writing code with large amounts of "template" code in them very easy.

You lose all of that if you write your own handler. Losing it will give you a performance boost, but not as much as you might think, a lot doesn't cost if it isn't used. Indeed, if you do lose stuff you need, your own methods of getting it back may well be less efficient.

If the natural way to write the handler in question would be to have everything happen directly or indirectly (method call) from a single event handler in your code-behind, and with an empty .aspx, then it may be clearer to write it as a handler instead, in which case do. Otherwise, you want to stick with the .aspx file.

Answer 4

Depending on what the page / handler is doing, I have had between 5 to 15% performance boost using plain handlers instead of pages - they are often a good choice for generating images, json, etc, handling background tasks from ajax requests, or doing things like visitor logging from image requests.

Handlers are a bit painful to use if you a writing out a lot of html - the potential for errors building up strings of html often outweighs the performance benefits.

One significant thing that you lose with a handler is no-brainer caching with the ouput cache declaration - you can of course wire it up yourself programatically, but I have found that aspnet usually does a better job of cache management than anything I write quickly.