Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > HttpHandlers - Learn Them. Use Them.

Reply
Thread Tools

HttpHandlers - Learn Them. Use Them.

 
 
Anonieko
Guest
Posts: n/a
 
      06-15-2006
HttpHandlers - Learn Them. Use Them.



Introduction

There are many features in ASP.NET that are unfortunately underused.
Sometimes a feature gets looked over because it's too complicated.
Other times, like in the case of HttpHandlers, it's because they are
poorly understood. For the longest time I understood the concept and
implementation of HttpHandlers, but I just couldn't figure out under
what circumstances I'd use them.

Googling HttpHandlers it's obvious to me that bad tech writers are
squarely to blame. A shameful amount of examples are nothing more than
"hello world." The problem with such a limited example is that it
leaves the reader thinking "so? I can do that with an aspx page!"
Without understanding what problem space HttpHandlers are meant for,
it's impossible to get developers to use them.

As an ASP.NET developer, HttpHandlers are important because they are
the earliest possible point where you have access to requests. When a
request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
the ASP.NET worker process internally creates an instance of the right
HttpHandler for the request in question and effectively hands off the
task of responding to the request. How does ASP.NET know which is the
right HttpHandler for a given request? Simple, via configuration files,
paths are mapped to http handlers. For example, if you open your
machine.config file you'll see a list of default mapping. For
example:

<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
<add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
<add verb="*" path="*.asmx"
type="System.Web.Services.Protocols.WebServiceHand lerFactory" />

So every time any .aspx page is requested, the PageHandlerFactory is
left to fulfill the request. HttpHandlers can also be added or changed
for specific sites in the web.config. Handlers aren't just mapped to
extensions, your own handler can be mapped to
"HandlePingback.aspx", in which case it, not the
PageHandlerFactory, will be called upon.

An HttpHandler is actually any class that implements the
System.Web.IHttpHandler interface. To be of any use it needs to be
mapped to a path. (I lie, PageHandlerFactory doesn't implement
IHttpHandler. Instead, it implements IHttpHandlerFactory.
IHttpHandlerFactory defines a method named GetHandler which returns an
IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
basically a layer between the internal ASP.NET process and the handoff
to the HttpHandler. Either way, in the end you end up with a class that
implements IHttpHandler). The IHttpHandler interfaces defines the very
important and aptly named ProcessRequest. Basically, this is ASP.NET
saying "hey you! Process this request!"


Built-in Handlers

If we look at the most important HttpHandler, the System.Web.UI.Page
class (yes, the same one that all your pages inherit from), we really
start to get a good feel for what an HttpHandler is responsible for.
Looking at the internals of the Page class and starting from the
ProcessRequest function, we quickly get to a ProcessRequestMain
function which really starts to interact with stuff you do on a daily
basis. Look at some of the stuff that happens in ProcessRequestMain:

....
base.InitRecursive(null);
if (context1.TraceIsEnabled)
{
this.Trace.Write("aspx.page", "End Init");
}
if (this.IsPostBack)
{
if (context1.TraceIsEnabled)
{
this.Trace.Write("aspx.page", "Begin LoadViewState");
}
this.LoadPageViewState();
if (context1.TraceIsEnabled)
{
this.Trace.Write("aspx.page", "End LoadViewState");
this.Trace.Write("aspx.page", "Begin ProcessPostData");
}
this.ProcessPostData(this._requestValueCollection, true);
if (context1.TraceIsEnabled)
{
this.Trace.Write("aspx.page", "End ProcessPostData");
}
}
base.LoadRecursive();
....


As you can see, it's this method that's responsible for causing all
those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
the Page class does what it's supposed to do: it's handling the
request.

Another handler we saw listed above is the HttpForbiddenHandler (which
is a straight handler as opposed to a HandlerFactory). A number of
paths are mapped to this handler - generally files that might
compromise a security risk if left publically accessible (like .config,
..cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
point:

public void ProcessRequest(HttpContext context)
{
PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
throw new HttpException(0x193,
HttpRuntime.FormatResourceString("Path_forbidden",
context.Request.Path));
}




Why use a handler?
There are likely few times where you have to use a handler. Almost
anything you can do in a handler, you could simply create an aspx page
to take care of. So why bother? There are two main reasons. First and
foremost, HttpHandlers are far more reusable/portable than pages. Since
there's no visual element to an HttpHandler (no .aspx), they can
easily be placed into their own assembly and reused from project to
project or even sold as is. Secondly, the Page handler is relatively
expensive. Going with the "Hello World" examples, if you do that in
a page you'll end up raising a number of events (onInit, onLoad,
onPreRender, onUnload, ...) and make use of a number of ASP.NET
features such as viewstate and postback. In most cases, the performance
hit is negligible, but it nonetheless highlights that you're using
the page framework when you have no need to.


Real Examples

The first example to look at is the TrackbackHandler than's part of
CommunityServer 1.1. If you go to http://code.communityserver.org/ and
open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
source code. The purpose of this handler is to track pingbacks made to
blog entries. Most blog engines will automatically send a pingback to
any linked posts. This means that blog engines must also have a way to
capture these pingbacks and record them. There's more or less a
standard between how the communication is supposed to happen, but each
blog engine is really on its own as far as implementation. Without
spending too much time in the code, we can see that the handler looks
for a number of POST parameters and creates the trackback based on
what's passed in.

There's absolutely no reason why all of this couldn't be done using
an ASPX page. But as I've already mentioned, that would force the
entire ASPX page framework to be invoked. Additionally, this handler
doesn't even have a visual element - so a page doesn't make too
much sense.

(you can look at the web.config to see how the handler's added).

Another example is my open source AMF.NET project which makes it
possible for a Flash application to communicate with server-side
ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
proprietary binary protocol used by Flash), executes the right server
side .NET function and returns a serialized response. Again, a single
ASP.NET page could be used to accomplish the same thing, but then it
would be impossible to package AMF.NET as a single assembly.

Another common example you'll run across is using HttpHandlers to
generate RSS feeds. Many applications will map "Rss.aspx" to an
HttpHandler which generates a XML feed.


Why not to use HttpHandlers

The biggest and very significant drawback of HttpHandlers is that they
can only be used for extensions that are mapped to ASP.NET in IIS. It
might be great to create a file download counter for your .zip files
using an HttpHandler, but since IIS doesn't go through ASP.NET to
serve .zip files, it isn't going to work. One solution is to map
those extra extension to ASP.NET, but that might have undesirable side
effects and might not even be possible for you (many developers don't
have direct access to IIS). In this case, the only solution is to
create an ISAPI filter which is much more difficult. IIS 7 promises to
let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
ASP.NET pipeline depending on how you look at it), but that's still a
ways away.

 
Reply With Quote
 
 
 
 
Karl Seguin [MVP]
Guest
Posts: n/a
 
      06-15-2006
Is there a reason you're trying to pass off someone else's work as your own?
As the author for these three pieces, I'm glad you saw value in what I
wrote, but don't appreciate having it spammed in a help newsgroup (which I
happen to spend a lot of time in) and I don't appreciate you not linking
back to the original content.

http://codebetter.com/blogs/karlseguin/

--
http://www.openmymind.net/
http://www.fuelindustries.com/


"Anonieko" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> HttpHandlers - Learn Them. Use Them.
>
>
>
> Introduction
>
> There are many features in ASP.NET that are unfortunately underused.
> Sometimes a feature gets looked over because it's too complicated.
> Other times, like in the case of HttpHandlers, it's because they are
> poorly understood. For the longest time I understood the concept and
> implementation of HttpHandlers, but I just couldn't figure out under
> what circumstances I'd use them.
>
> Googling HttpHandlers it's obvious to me that bad tech writers are
> squarely to blame. A shameful amount of examples are nothing more than
> "hello world." The problem with such a limited example is that it
> leaves the reader thinking "so? I can do that with an aspx page!"
> Without understanding what problem space HttpHandlers are meant for,
> it's impossible to get developers to use them.
>
> As an ASP.NET developer, HttpHandlers are important because they are
> the earliest possible point where you have access to requests. When a
> request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
> the ASP.NET worker process internally creates an instance of the right
> HttpHandler for the request in question and effectively hands off the
> task of responding to the request. How does ASP.NET know which is the
> right HttpHandler for a given request? Simple, via configuration files,
> paths are mapped to http handlers. For example, if you open your
> machine.config file you'll see a list of default mapping. For
> example:
>
> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
> <add verb="*" path="*.asmx"
> type="System.Web.Services.Protocols.WebServiceHand lerFactory" />
>
> So every time any .aspx page is requested, the PageHandlerFactory is
> left to fulfill the request. HttpHandlers can also be added or changed
> for specific sites in the web.config. Handlers aren't just mapped to
> extensions, your own handler can be mapped to
> "HandlePingback.aspx", in which case it, not the
> PageHandlerFactory, will be called upon.
>
> An HttpHandler is actually any class that implements the
> System.Web.IHttpHandler interface. To be of any use it needs to be
> mapped to a path. (I lie, PageHandlerFactory doesn't implement
> IHttpHandler. Instead, it implements IHttpHandlerFactory.
> IHttpHandlerFactory defines a method named GetHandler which returns an
> IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
> basically a layer between the internal ASP.NET process and the handoff
> to the HttpHandler. Either way, in the end you end up with a class that
> implements IHttpHandler). The IHttpHandler interfaces defines the very
> important and aptly named ProcessRequest. Basically, this is ASP.NET
> saying "hey you! Process this request!"
>
>
> Built-in Handlers
>
> If we look at the most important HttpHandler, the System.Web.UI.Page
> class (yes, the same one that all your pages inherit from), we really
> start to get a good feel for what an HttpHandler is responsible for.
> Looking at the internals of the Page class and starting from the
> ProcessRequest function, we quickly get to a ProcessRequestMain
> function which really starts to interact with stuff you do on a daily
> basis. Look at some of the stuff that happens in ProcessRequestMain:
>
> ...
> base.InitRecursive(null);
> if (context1.TraceIsEnabled)
> {
> this.Trace.Write("aspx.page", "End Init");
> }
> if (this.IsPostBack)
> {
> if (context1.TraceIsEnabled)
> {
> this.Trace.Write("aspx.page", "Begin LoadViewState");
> }
> this.LoadPageViewState();
> if (context1.TraceIsEnabled)
> {
> this.Trace.Write("aspx.page", "End LoadViewState");
> this.Trace.Write("aspx.page", "Begin ProcessPostData");
> }
> this.ProcessPostData(this._requestValueCollection, true);
> if (context1.TraceIsEnabled)
> {
> this.Trace.Write("aspx.page", "End ProcessPostData");
> }
> }
> base.LoadRecursive();
> ...
>
>
> As you can see, it's this method that's responsible for causing all
> those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
> the Page class does what it's supposed to do: it's handling the
> request.
>
> Another handler we saw listed above is the HttpForbiddenHandler (which
> is a straight handler as opposed to a HandlerFactory). A number of
> paths are mapped to this handler - generally files that might
> compromise a security risk if left publically accessible (like .config,
> .cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
> point:
>
> public void ProcessRequest(HttpContext context)
> {
> PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
> throw new HttpException(0x193,
> HttpRuntime.FormatResourceString("Path_forbidden",
> context.Request.Path));
> }
>
>
>
>
> Why use a handler?
> There are likely few times where you have to use a handler. Almost
> anything you can do in a handler, you could simply create an aspx page
> to take care of. So why bother? There are two main reasons. First and
> foremost, HttpHandlers are far more reusable/portable than pages. Since
> there's no visual element to an HttpHandler (no .aspx), they can
> easily be placed into their own assembly and reused from project to
> project or even sold as is. Secondly, the Page handler is relatively
> expensive. Going with the "Hello World" examples, if you do that in
> a page you'll end up raising a number of events (onInit, onLoad,
> onPreRender, onUnload, ...) and make use of a number of ASP.NET
> features such as viewstate and postback. In most cases, the performance
> hit is negligible, but it nonetheless highlights that you're using
> the page framework when you have no need to.
>
>
> Real Examples
>
> The first example to look at is the TrackbackHandler than's part of
> CommunityServer 1.1. If you go to http://code.communityserver.org/ and
> open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
> source code. The purpose of this handler is to track pingbacks made to
> blog entries. Most blog engines will automatically send a pingback to
> any linked posts. This means that blog engines must also have a way to
> capture these pingbacks and record them. There's more or less a
> standard between how the communication is supposed to happen, but each
> blog engine is really on its own as far as implementation. Without
> spending too much time in the code, we can see that the handler looks
> for a number of POST parameters and creates the trackback based on
> what's passed in.
>
> There's absolutely no reason why all of this couldn't be done using
> an ASPX page. But as I've already mentioned, that would force the
> entire ASPX page framework to be invoked. Additionally, this handler
> doesn't even have a visual element - so a page doesn't make too
> much sense.
>
> (you can look at the web.config to see how the handler's added).
>
> Another example is my open source AMF.NET project which makes it
> possible for a Flash application to communicate with server-side
> ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
> proprietary binary protocol used by Flash), executes the right server
> side .NET function and returns a serialized response. Again, a single
> ASP.NET page could be used to accomplish the same thing, but then it
> would be impossible to package AMF.NET as a single assembly.
>
> Another common example you'll run across is using HttpHandlers to
> generate RSS feeds. Many applications will map "Rss.aspx" to an
> HttpHandler which generates a XML feed.
>
>
> Why not to use HttpHandlers
>
> The biggest and very significant drawback of HttpHandlers is that they
> can only be used for extensions that are mapped to ASP.NET in IIS. It
> might be great to create a file download counter for your .zip files
> using an HttpHandler, but since IIS doesn't go through ASP.NET to
> serve .zip files, it isn't going to work. One solution is to map
> those extra extension to ASP.NET, but that might have undesirable side
> effects and might not even be possible for you (many developers don't
> have direct access to IIS). In this case, the only solution is to
> create an ISAPI filter which is much more difficult. IIS 7 promises to
> let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
> ASP.NET pipeline depending on how you look at it), but that's still a
> ways away.
>



 
Reply With Quote
 
 
 
 
Edwin Knoppert
Guest
Posts: n/a
 
      06-16-2006
Good topic though, bookmarked




"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:(E-Mail Removed)...
> Is there a reason you're trying to pass off someone else's work as your
> own? As the author for these three pieces, I'm glad you saw value in what
> I wrote, but don't appreciate having it spammed in a help newsgroup (which
> I happen to spend a lot of time in) and I don't appreciate you not linking
> back to the original content.
>
> http://codebetter.com/blogs/karlseguin/
>
> --
> http://www.openmymind.net/
> http://www.fuelindustries.com/
>
>
> "Anonieko" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
>> HttpHandlers - Learn Them. Use Them.
>>
>>
>>
>> Introduction
>>
>> There are many features in ASP.NET that are unfortunately underused.
>> Sometimes a feature gets looked over because it's too complicated.
>> Other times, like in the case of HttpHandlers, it's because they are
>> poorly understood. For the longest time I understood the concept and
>> implementation of HttpHandlers, but I just couldn't figure out under
>> what circumstances I'd use them.
>>
>> Googling HttpHandlers it's obvious to me that bad tech writers are
>> squarely to blame. A shameful amount of examples are nothing more than
>> "hello world." The problem with such a limited example is that it
>> leaves the reader thinking "so? I can do that with an aspx page!"
>> Without understanding what problem space HttpHandlers are meant for,
>> it's impossible to get developers to use them.
>>
>> As an ASP.NET developer, HttpHandlers are important because they are
>> the earliest possible point where you have access to requests. When a
>> request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
>> the ASP.NET worker process internally creates an instance of the right
>> HttpHandler for the request in question and effectively hands off the
>> task of responding to the request. How does ASP.NET know which is the
>> right HttpHandler for a given request? Simple, via configuration files,
>> paths are mapped to http handlers. For example, if you open your
>> machine.config file you'll see a list of default mapping. For
>> example:
>>
>> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
>> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
>> <add verb="*" path="*.asmx"
>> type="System.Web.Services.Protocols.WebServiceHand lerFactory" />
>>
>> So every time any .aspx page is requested, the PageHandlerFactory is
>> left to fulfill the request. HttpHandlers can also be added or changed
>> for specific sites in the web.config. Handlers aren't just mapped to
>> extensions, your own handler can be mapped to
>> "HandlePingback.aspx", in which case it, not the
>> PageHandlerFactory, will be called upon.
>>
>> An HttpHandler is actually any class that implements the
>> System.Web.IHttpHandler interface. To be of any use it needs to be
>> mapped to a path. (I lie, PageHandlerFactory doesn't implement
>> IHttpHandler. Instead, it implements IHttpHandlerFactory.
>> IHttpHandlerFactory defines a method named GetHandler which returns an
>> IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
>> basically a layer between the internal ASP.NET process and the handoff
>> to the HttpHandler. Either way, in the end you end up with a class that
>> implements IHttpHandler). The IHttpHandler interfaces defines the very
>> important and aptly named ProcessRequest. Basically, this is ASP.NET
>> saying "hey you! Process this request!"
>>
>>
>> Built-in Handlers
>>
>> If we look at the most important HttpHandler, the System.Web.UI.Page
>> class (yes, the same one that all your pages inherit from), we really
>> start to get a good feel for what an HttpHandler is responsible for.
>> Looking at the internals of the Page class and starting from the
>> ProcessRequest function, we quickly get to a ProcessRequestMain
>> function which really starts to interact with stuff you do on a daily
>> basis. Look at some of the stuff that happens in ProcessRequestMain:
>>
>> ...
>> base.InitRecursive(null);
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End Init");
>> }
>> if (this.IsPostBack)
>> {
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "Begin LoadViewState");
>> }
>> this.LoadPageViewState();
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End LoadViewState");
>> this.Trace.Write("aspx.page", "Begin ProcessPostData");
>> }
>> this.ProcessPostData(this._requestValueCollection, true);
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End ProcessPostData");
>> }
>> }
>> base.LoadRecursive();
>> ...
>>
>>
>> As you can see, it's this method that's responsible for causing all
>> those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
>> the Page class does what it's supposed to do: it's handling the
>> request.
>>
>> Another handler we saw listed above is the HttpForbiddenHandler (which
>> is a straight handler as opposed to a HandlerFactory). A number of
>> paths are mapped to this handler - generally files that might
>> compromise a security risk if left publically accessible (like .config,
>> .cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
>> point:
>>
>> public void ProcessRequest(HttpContext context)
>> {
>> PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
>> throw new HttpException(0x193,
>> HttpRuntime.FormatResourceString("Path_forbidden",
>> context.Request.Path));
>> }
>>
>>
>>
>>
>> Why use a handler?
>> There are likely few times where you have to use a handler. Almost
>> anything you can do in a handler, you could simply create an aspx page
>> to take care of. So why bother? There are two main reasons. First and
>> foremost, HttpHandlers are far more reusable/portable than pages. Since
>> there's no visual element to an HttpHandler (no .aspx), they can
>> easily be placed into their own assembly and reused from project to
>> project or even sold as is. Secondly, the Page handler is relatively
>> expensive. Going with the "Hello World" examples, if you do that in
>> a page you'll end up raising a number of events (onInit, onLoad,
>> onPreRender, onUnload, ...) and make use of a number of ASP.NET
>> features such as viewstate and postback. In most cases, the performance
>> hit is negligible, but it nonetheless highlights that you're using
>> the page framework when you have no need to.
>>
>>
>> Real Examples
>>
>> The first example to look at is the TrackbackHandler than's part of
>> CommunityServer 1.1. If you go to http://code.communityserver.org/ and
>> open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
>> source code. The purpose of this handler is to track pingbacks made to
>> blog entries. Most blog engines will automatically send a pingback to
>> any linked posts. This means that blog engines must also have a way to
>> capture these pingbacks and record them. There's more or less a
>> standard between how the communication is supposed to happen, but each
>> blog engine is really on its own as far as implementation. Without
>> spending too much time in the code, we can see that the handler looks
>> for a number of POST parameters and creates the trackback based on
>> what's passed in.
>>
>> There's absolutely no reason why all of this couldn't be done using
>> an ASPX page. But as I've already mentioned, that would force the
>> entire ASPX page framework to be invoked. Additionally, this handler
>> doesn't even have a visual element - so a page doesn't make too
>> much sense.
>>
>> (you can look at the web.config to see how the handler's added).
>>
>> Another example is my open source AMF.NET project which makes it
>> possible for a Flash application to communicate with server-side
>> ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
>> proprietary binary protocol used by Flash), executes the right server
>> side .NET function and returns a serialized response. Again, a single
>> ASP.NET page could be used to accomplish the same thing, but then it
>> would be impossible to package AMF.NET as a single assembly.
>>
>> Another common example you'll run across is using HttpHandlers to
>> generate RSS feeds. Many applications will map "Rss.aspx" to an
>> HttpHandler which generates a XML feed.
>>
>>
>> Why not to use HttpHandlers
>>
>> The biggest and very significant drawback of HttpHandlers is that they
>> can only be used for extensions that are mapped to ASP.NET in IIS. It
>> might be great to create a file download counter for your .zip files
>> using an HttpHandler, but since IIS doesn't go through ASP.NET to
>> serve .zip files, it isn't going to work. One solution is to map
>> those extra extension to ASP.NET, but that might have undesirable side
>> effects and might not even be possible for you (many developers don't
>> have direct access to IIS). In this case, the only solution is to
>> create an ISAPI filter which is much more difficult. IIS 7 promises to
>> let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
>> ASP.NET pipeline depending on how you look at it), but that's still a
>> ways away.
>>

>
>



 
Reply With Quote
 
Edwin Knoppert
Guest
Posts: n/a
 
      06-16-2006
6 - '.Fomrmat' and '.AppendFormat'

Oops

"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:(E-Mail Removed)...
> Is there a reason you're trying to pass off someone else's work as your
> own? As the author for these three pieces, I'm glad you saw value in what
> I wrote, but don't appreciate having it spammed in a help newsgroup (which
> I happen to spend a lot of time in) and I don't appreciate you not linking
> back to the original content.
>
> http://codebetter.com/blogs/karlseguin/
>
> --
> http://www.openmymind.net/
> http://www.fuelindustries.com/
>
>
> "Anonieko" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
>> HttpHandlers - Learn Them. Use Them.
>>
>>
>>
>> Introduction
>>
>> There are many features in ASP.NET that are unfortunately underused.
>> Sometimes a feature gets looked over because it's too complicated.
>> Other times, like in the case of HttpHandlers, it's because they are
>> poorly understood. For the longest time I understood the concept and
>> implementation of HttpHandlers, but I just couldn't figure out under
>> what circumstances I'd use them.
>>
>> Googling HttpHandlers it's obvious to me that bad tech writers are
>> squarely to blame. A shameful amount of examples are nothing more than
>> "hello world." The problem with such a limited example is that it
>> leaves the reader thinking "so? I can do that with an aspx page!"
>> Without understanding what problem space HttpHandlers are meant for,
>> it's impossible to get developers to use them.
>>
>> As an ASP.NET developer, HttpHandlers are important because they are
>> the earliest possible point where you have access to requests. When a
>> request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
>> the ASP.NET worker process internally creates an instance of the right
>> HttpHandler for the request in question and effectively hands off the
>> task of responding to the request. How does ASP.NET know which is the
>> right HttpHandler for a given request? Simple, via configuration files,
>> paths are mapped to http handlers. For example, if you open your
>> machine.config file you'll see a list of default mapping. For
>> example:
>>
>> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
>> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
>> <add verb="*" path="*.asmx"
>> type="System.Web.Services.Protocols.WebServiceHand lerFactory" />
>>
>> So every time any .aspx page is requested, the PageHandlerFactory is
>> left to fulfill the request. HttpHandlers can also be added or changed
>> for specific sites in the web.config. Handlers aren't just mapped to
>> extensions, your own handler can be mapped to
>> "HandlePingback.aspx", in which case it, not the
>> PageHandlerFactory, will be called upon.
>>
>> An HttpHandler is actually any class that implements the
>> System.Web.IHttpHandler interface. To be of any use it needs to be
>> mapped to a path. (I lie, PageHandlerFactory doesn't implement
>> IHttpHandler. Instead, it implements IHttpHandlerFactory.
>> IHttpHandlerFactory defines a method named GetHandler which returns an
>> IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
>> basically a layer between the internal ASP.NET process and the handoff
>> to the HttpHandler. Either way, in the end you end up with a class that
>> implements IHttpHandler). The IHttpHandler interfaces defines the very
>> important and aptly named ProcessRequest. Basically, this is ASP.NET
>> saying "hey you! Process this request!"
>>
>>
>> Built-in Handlers
>>
>> If we look at the most important HttpHandler, the System.Web.UI.Page
>> class (yes, the same one that all your pages inherit from), we really
>> start to get a good feel for what an HttpHandler is responsible for.
>> Looking at the internals of the Page class and starting from the
>> ProcessRequest function, we quickly get to a ProcessRequestMain
>> function which really starts to interact with stuff you do on a daily
>> basis. Look at some of the stuff that happens in ProcessRequestMain:
>>
>> ...
>> base.InitRecursive(null);
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End Init");
>> }
>> if (this.IsPostBack)
>> {
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "Begin LoadViewState");
>> }
>> this.LoadPageViewState();
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End LoadViewState");
>> this.Trace.Write("aspx.page", "Begin ProcessPostData");
>> }
>> this.ProcessPostData(this._requestValueCollection, true);
>> if (context1.TraceIsEnabled)
>> {
>> this.Trace.Write("aspx.page", "End ProcessPostData");
>> }
>> }
>> base.LoadRecursive();
>> ...
>>
>>
>> As you can see, it's this method that's responsible for causing all
>> those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
>> the Page class does what it's supposed to do: it's handling the
>> request.
>>
>> Another handler we saw listed above is the HttpForbiddenHandler (which
>> is a straight handler as opposed to a HandlerFactory). A number of
>> paths are mapped to this handler - generally files that might
>> compromise a security risk if left publically accessible (like .config,
>> .cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
>> point:
>>
>> public void ProcessRequest(HttpContext context)
>> {
>> PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
>> throw new HttpException(0x193,
>> HttpRuntime.FormatResourceString("Path_forbidden",
>> context.Request.Path));
>> }
>>
>>
>>
>>
>> Why use a handler?
>> There are likely few times where you have to use a handler. Almost
>> anything you can do in a handler, you could simply create an aspx page
>> to take care of. So why bother? There are two main reasons. First and
>> foremost, HttpHandlers are far more reusable/portable than pages. Since
>> there's no visual element to an HttpHandler (no .aspx), they can
>> easily be placed into their own assembly and reused from project to
>> project or even sold as is. Secondly, the Page handler is relatively
>> expensive. Going with the "Hello World" examples, if you do that in
>> a page you'll end up raising a number of events (onInit, onLoad,
>> onPreRender, onUnload, ...) and make use of a number of ASP.NET
>> features such as viewstate and postback. In most cases, the performance
>> hit is negligible, but it nonetheless highlights that you're using
>> the page framework when you have no need to.
>>
>>
>> Real Examples
>>
>> The first example to look at is the TrackbackHandler than's part of
>> CommunityServer 1.1. If you go to http://code.communityserver.org/ and
>> open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
>> source code. The purpose of this handler is to track pingbacks made to
>> blog entries. Most blog engines will automatically send a pingback to
>> any linked posts. This means that blog engines must also have a way to
>> capture these pingbacks and record them. There's more or less a
>> standard between how the communication is supposed to happen, but each
>> blog engine is really on its own as far as implementation. Without
>> spending too much time in the code, we can see that the handler looks
>> for a number of POST parameters and creates the trackback based on
>> what's passed in.
>>
>> There's absolutely no reason why all of this couldn't be done using
>> an ASPX page. But as I've already mentioned, that would force the
>> entire ASPX page framework to be invoked. Additionally, this handler
>> doesn't even have a visual element - so a page doesn't make too
>> much sense.
>>
>> (you can look at the web.config to see how the handler's added).
>>
>> Another example is my open source AMF.NET project which makes it
>> possible for a Flash application to communicate with server-side
>> ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
>> proprietary binary protocol used by Flash), executes the right server
>> side .NET function and returns a serialized response. Again, a single
>> ASP.NET page could be used to accomplish the same thing, but then it
>> would be impossible to package AMF.NET as a single assembly.
>>
>> Another common example you'll run across is using HttpHandlers to
>> generate RSS feeds. Many applications will map "Rss.aspx" to an
>> HttpHandler which generates a XML feed.
>>
>>
>> Why not to use HttpHandlers
>>
>> The biggest and very significant drawback of HttpHandlers is that they
>> can only be used for extensions that are mapped to ASP.NET in IIS. It
>> might be great to create a file download counter for your .zip files
>> using an HttpHandler, but since IIS doesn't go through ASP.NET to
>> serve .zip files, it isn't going to work. One solution is to map
>> those extra extension to ASP.NET, but that might have undesirable side
>> effects and might not even be possible for you (many developers don't
>> have direct access to IIS). In this case, the only solution is to
>> create an ISAPI filter which is much more difficult. IIS 7 promises to
>> let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
>> ASP.NET pipeline depending on how you look at it), but that's still a
>> ways away.
>>

>
>



 
Reply With Quote
 
Edwin Knoppert
Guest
Posts: n/a
 
      06-16-2006
I wonder.. sqldatassource is discouraged.. why?
I'm using it icw the gridview.
Am i mistaken?
To bad the reasons are not menioned.



"Edwin Knoppert" <(E-Mail Removed)> schreef in bericht
news:4492c22e$0$2032$(E-Mail Removed). ..
> Good topic though, bookmarked
>
>
>
>
> "Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
> net> schreef in bericht news:(E-Mail Removed)...
>> Is there a reason you're trying to pass off someone else's work as your
>> own? As the author for these three pieces, I'm glad you saw value in what
>> I wrote, but don't appreciate having it spammed in a help newsgroup
>> (which I happen to spend a lot of time in) and I don't appreciate you not
>> linking back to the original content.
>>
>> http://codebetter.com/blogs/karlseguin/
>>
>> --
>> http://www.openmymind.net/
>> http://www.fuelindustries.com/
>>
>>
>> "Anonieko" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ups.com...
>>> HttpHandlers - Learn Them. Use Them.
>>>
>>>
>>>
>>> Introduction
>>>
>>> There are many features in ASP.NET that are unfortunately underused.
>>> Sometimes a feature gets looked over because it's too complicated.
>>> Other times, like in the case of HttpHandlers, it's because they are
>>> poorly understood. For the longest time I understood the concept and
>>> implementation of HttpHandlers, but I just couldn't figure out under
>>> what circumstances I'd use them.
>>>
>>> Googling HttpHandlers it's obvious to me that bad tech writers are
>>> squarely to blame. A shameful amount of examples are nothing more than
>>> "hello world." The problem with such a limited example is that it
>>> leaves the reader thinking "so? I can do that with an aspx page!"
>>> Without understanding what problem space HttpHandlers are meant for,
>>> it's impossible to get developers to use them.
>>>
>>> As an ASP.NET developer, HttpHandlers are important because they are
>>> the earliest possible point where you have access to requests. When a
>>> request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
>>> the ASP.NET worker process internally creates an instance of the right
>>> HttpHandler for the request in question and effectively hands off the
>>> task of responding to the request. How does ASP.NET know which is the
>>> right HttpHandler for a given request? Simple, via configuration files,
>>> paths are mapped to http handlers. For example, if you open your
>>> machine.config file you'll see a list of default mapping. For
>>> example:
>>>
>>> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
>>> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
>>> <add verb="*" path="*.asmx"
>>> type="System.Web.Services.Protocols.WebServiceHand lerFactory" />
>>>
>>> So every time any .aspx page is requested, the PageHandlerFactory is
>>> left to fulfill the request. HttpHandlers can also be added or changed
>>> for specific sites in the web.config. Handlers aren't just mapped to
>>> extensions, your own handler can be mapped to
>>> "HandlePingback.aspx", in which case it, not the
>>> PageHandlerFactory, will be called upon.
>>>
>>> An HttpHandler is actually any class that implements the
>>> System.Web.IHttpHandler interface. To be of any use it needs to be
>>> mapped to a path. (I lie, PageHandlerFactory doesn't implement
>>> IHttpHandler. Instead, it implements IHttpHandlerFactory.
>>> IHttpHandlerFactory defines a method named GetHandler which returns an
>>> IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
>>> basically a layer between the internal ASP.NET process and the handoff
>>> to the HttpHandler. Either way, in the end you end up with a class that
>>> implements IHttpHandler). The IHttpHandler interfaces defines the very
>>> important and aptly named ProcessRequest. Basically, this is ASP.NET
>>> saying "hey you! Process this request!"
>>>
>>>
>>> Built-in Handlers
>>>
>>> If we look at the most important HttpHandler, the System.Web.UI.Page
>>> class (yes, the same one that all your pages inherit from), we really
>>> start to get a good feel for what an HttpHandler is responsible for.
>>> Looking at the internals of the Page class and starting from the
>>> ProcessRequest function, we quickly get to a ProcessRequestMain
>>> function which really starts to interact with stuff you do on a daily
>>> basis. Look at some of the stuff that happens in ProcessRequestMain:
>>>
>>> ...
>>> base.InitRecursive(null);
>>> if (context1.TraceIsEnabled)
>>> {
>>> this.Trace.Write("aspx.page", "End Init");
>>> }
>>> if (this.IsPostBack)
>>> {
>>> if (context1.TraceIsEnabled)
>>> {
>>> this.Trace.Write("aspx.page", "Begin LoadViewState");
>>> }
>>> this.LoadPageViewState();
>>> if (context1.TraceIsEnabled)
>>> {
>>> this.Trace.Write("aspx.page", "End LoadViewState");
>>> this.Trace.Write("aspx.page", "Begin ProcessPostData");
>>> }
>>> this.ProcessPostData(this._requestValueCollection, true);
>>> if (context1.TraceIsEnabled)
>>> {
>>> this.Trace.Write("aspx.page", "End ProcessPostData");
>>> }
>>> }
>>> base.LoadRecursive();
>>> ...
>>>
>>>
>>> As you can see, it's this method that's responsible for causing all
>>> those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
>>> the Page class does what it's supposed to do: it's handling the
>>> request.
>>>
>>> Another handler we saw listed above is the HttpForbiddenHandler (which
>>> is a straight handler as opposed to a HandlerFactory). A number of
>>> paths are mapped to this handler - generally files that might
>>> compromise a security risk if left publically accessible (like .config,
>>> .cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
>>> point:
>>>
>>> public void ProcessRequest(HttpContext context)
>>> {
>>> PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
>>> throw new HttpException(0x193,
>>> HttpRuntime.FormatResourceString("Path_forbidden",
>>> context.Request.Path));
>>> }
>>>
>>>
>>>
>>>
>>> Why use a handler?
>>> There are likely few times where you have to use a handler. Almost
>>> anything you can do in a handler, you could simply create an aspx page
>>> to take care of. So why bother? There are two main reasons. First and
>>> foremost, HttpHandlers are far more reusable/portable than pages. Since
>>> there's no visual element to an HttpHandler (no .aspx), they can
>>> easily be placed into their own assembly and reused from project to
>>> project or even sold as is. Secondly, the Page handler is relatively
>>> expensive. Going with the "Hello World" examples, if you do that in
>>> a page you'll end up raising a number of events (onInit, onLoad,
>>> onPreRender, onUnload, ...) and make use of a number of ASP.NET
>>> features such as viewstate and postback. In most cases, the performance
>>> hit is negligible, but it nonetheless highlights that you're using
>>> the page framework when you have no need to.
>>>
>>>
>>> Real Examples
>>>
>>> The first example to look at is the TrackbackHandler than's part of
>>> CommunityServer 1.1. If you go to http://code.communityserver.org/ and
>>> open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
>>> source code. The purpose of this handler is to track pingbacks made to
>>> blog entries. Most blog engines will automatically send a pingback to
>>> any linked posts. This means that blog engines must also have a way to
>>> capture these pingbacks and record them. There's more or less a
>>> standard between how the communication is supposed to happen, but each
>>> blog engine is really on its own as far as implementation. Without
>>> spending too much time in the code, we can see that the handler looks
>>> for a number of POST parameters and creates the trackback based on
>>> what's passed in.
>>>
>>> There's absolutely no reason why all of this couldn't be done using
>>> an ASPX page. But as I've already mentioned, that would force the
>>> entire ASPX page framework to be invoked. Additionally, this handler
>>> doesn't even have a visual element - so a page doesn't make too
>>> much sense.
>>>
>>> (you can look at the web.config to see how the handler's added).
>>>
>>> Another example is my open source AMF.NET project which makes it
>>> possible for a Flash application to communicate with server-side
>>> ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
>>> proprietary binary protocol used by Flash), executes the right server
>>> side .NET function and returns a serialized response. Again, a single
>>> ASP.NET page could be used to accomplish the same thing, but then it
>>> would be impossible to package AMF.NET as a single assembly.
>>>
>>> Another common example you'll run across is using HttpHandlers to
>>> generate RSS feeds. Many applications will map "Rss.aspx" to an
>>> HttpHandler which generates a XML feed.
>>>
>>>
>>> Why not to use HttpHandlers
>>>
>>> The biggest and very significant drawback of HttpHandlers is that they
>>> can only be used for extensions that are mapped to ASP.NET in IIS. It
>>> might be great to create a file download counter for your .zip files
>>> using an HttpHandler, but since IIS doesn't go through ASP.NET to
>>> serve .zip files, it isn't going to work. One solution is to map
>>> those extra extension to ASP.NET, but that might have undesirable side
>>> effects and might not even be possible for you (many developers don't
>>> have direct access to IIS). In this case, the only solution is to
>>> create an ISAPI filter which is much more difficult. IIS 7 promises to
>>> let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
>>> ASP.NET pipeline depending on how you look at it), but that's still a
>>> ways away.
>>>

>>
>>

>
>



 
Reply With Quote
 
tdavisjr
Guest
Posts: n/a
 
      06-16-2006
Hey..I know I read this article already. What a shame, didn't even
mention the original author. Looks like we will soon have to copyright
blogs.


Edwin Knoppert wrote:
> I wonder.. sqldatassource is discouraged.. why?
> I'm using it icw the gridview.
> Am i mistaken?
> To bad the reasons are not menioned.
>
>
>
> "Edwin Knoppert" <(E-Mail Removed)> schreef in bericht
> news:4492c22e$0$2032$(E-Mail Removed). ..
> > Good topic though, bookmarked
> >
> >
> >
> >
> > "Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
> > net> schreef in bericht news:(E-Mail Removed)...
> >> Is there a reason you're trying to pass off someone else's work as your
> >> own? As the author for these three pieces, I'm glad you saw value in what
> >> I wrote, but don't appreciate having it spammed in a help newsgroup
> >> (which I happen to spend a lot of time in) and I don't appreciate you not
> >> linking back to the original content.
> >>
> >> http://codebetter.com/blogs/karlseguin/
> >>
> >> --
> >> http://www.openmymind.net/
> >> http://www.fuelindustries.com/
> >>
> >>
> >> "Anonieko" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed) ups.com...
> >>> HttpHandlers - Learn Them. Use Them.
> >>>
> >>>
> >>>
> >>> Introduction
> >>>
> >>> There are many features in ASP.NET that are unfortunately underused.
> >>> Sometimes a feature gets looked over because it's too complicated.
> >>> Other times, like in the case of HttpHandlers, it's because they are
> >>> poorly understood. For the longest time I understood the concept and
> >>> implementation of HttpHandlers, but I just couldn't figure out under
> >>> what circumstances I'd use them.
> >>>
> >>> Googling HttpHandlers it's obvious to me that bad tech writers are
> >>> squarely to blame. A shameful amount of examples are nothing more than
> >>> "hello world." The problem with such a limited example is that it
> >>> leaves the reader thinking "so? I can do that with an aspx page!"
> >>> Without understanding what problem space HttpHandlers are meant for,
> >>> it's impossible to get developers to use them.
> >>>
> >>> As an ASP.NET developer, HttpHandlers are important because they are
> >>> the earliest possible point where you have access to requests. When a
> >>> request is made to IIS for an ASP.NET resource (.aspx, .config, .asmx),
> >>> the ASP.NET worker process internally creates an instance of the right
> >>> HttpHandler for the request in question and effectively hands off the
> >>> task of responding to the request. How does ASP.NET know which is the
> >>> right HttpHandler for a given request? Simple, via configuration files,
> >>> paths are mapped to http handlers. For example, if you open your
> >>> machine.config file you'll see a list of default mapping. For
> >>> example:
> >>>
> >>> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
> >>> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
> >>> <add verb="*" path="*.asmx"
> >>> type="System.Web.Services.Protocols.WebServiceHand lerFactory" />
> >>>
> >>> So every time any .aspx page is requested, the PageHandlerFactory is
> >>> left to fulfill the request. HttpHandlers can also be added or changed
> >>> for specific sites in the web.config. Handlers aren't just mapped to
> >>> extensions, your own handler can be mapped to
> >>> "HandlePingback.aspx", in which case it, not the
> >>> PageHandlerFactory, will be called upon.
> >>>
> >>> An HttpHandler is actually any class that implements the
> >>> System.Web.IHttpHandler interface. To be of any use it needs to be
> >>> mapped to a path. (I lie, PageHandlerFactory doesn't implement
> >>> IHttpHandler. Instead, it implements IHttpHandlerFactory.
> >>> IHttpHandlerFactory defines a method named GetHandler which returns an
> >>> IHttpHandler. We won't cover IHttpHandlerFactories here, but it's
> >>> basically a layer between the internal ASP.NET process and the handoff
> >>> to the HttpHandler. Either way, in the end you end up with a class that
> >>> implements IHttpHandler). The IHttpHandler interfaces defines the very
> >>> important and aptly named ProcessRequest. Basically, this is ASP.NET
> >>> saying "hey you! Process this request!"
> >>>
> >>>
> >>> Built-in Handlers
> >>>
> >>> If we look at the most important HttpHandler, the System.Web.UI.Page
> >>> class (yes, the same one that all your pages inherit from), we really
> >>> start to get a good feel for what an HttpHandler is responsible for.
> >>> Looking at the internals of the Page class and starting from the
> >>> ProcessRequest function, we quickly get to a ProcessRequestMain
> >>> function which really starts to interact with stuff you do on a daily
> >>> basis. Look at some of the stuff that happens in ProcessRequestMain:
> >>>
> >>> ...
> >>> base.InitRecursive(null);
> >>> if (context1.TraceIsEnabled)
> >>> {
> >>> this.Trace.Write("aspx.page", "End Init");
> >>> }
> >>> if (this.IsPostBack)
> >>> {
> >>> if (context1.TraceIsEnabled)
> >>> {
> >>> this.Trace.Write("aspx.page", "Begin LoadViewState");
> >>> }
> >>> this.LoadPageViewState();
> >>> if (context1.TraceIsEnabled)
> >>> {
> >>> this.Trace.Write("aspx.page", "End LoadViewState");
> >>> this.Trace.Write("aspx.page", "Begin ProcessPostData");
> >>> }
> >>> this.ProcessPostData(this._requestValueCollection, true);
> >>> if (context1.TraceIsEnabled)
> >>> {
> >>> this.Trace.Write("aspx.page", "End ProcessPostData");
> >>> }
> >>> }
> >>> base.LoadRecursive();
> >>> ...
> >>>
> >>>
> >>> As you can see, it's this method that's responsible for causing all
> >>> those ASPX events, such as OnInit and OnLoad, to be raised. In essence,
> >>> the Page class does what it's supposed to do: it's handling the
> >>> request.
> >>>
> >>> Another handler we saw listed above is the HttpForbiddenHandler (which
> >>> is a straight handler as opposed to a HandlerFactory). A number of
> >>> paths are mapped to this handler - generally files that might
> >>> compromise a security risk if left publically accessible (like .config,
> >>> .cs, .vb, .dll, ...). The ProcessRequest for this handler is to the
> >>> point:
> >>>
> >>> public void ProcessRequest(HttpContext context)
> >>> {
> >>> PerfCounters.IncrementCounter(AppPerfCounter.REQUE STS_NOT_FOUND);
> >>> throw new HttpException(0x193,
> >>> HttpRuntime.FormatResourceString("Path_forbidden",
> >>> context.Request.Path));
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>> Why use a handler?
> >>> There are likely few times where you have to use a handler. Almost
> >>> anything you can do in a handler, you could simply create an aspx page
> >>> to take care of. So why bother? There are two main reasons. First and
> >>> foremost, HttpHandlers are far more reusable/portable than pages. Since
> >>> there's no visual element to an HttpHandler (no .aspx), they can
> >>> easily be placed into their own assembly and reused from project to
> >>> project or even sold as is. Secondly, the Page handler is relatively
> >>> expensive. Going with the "Hello World" examples, if you do that in
> >>> a page you'll end up raising a number of events (onInit, onLoad,
> >>> onPreRender, onUnload, ...) and make use of a number of ASP.NET
> >>> features such as viewstate and postback. In most cases, the performance
> >>> hit is negligible, but it nonetheless highlights that you're using
> >>> the page framework when you have no need to.
> >>>
> >>>
> >>> Real Examples
> >>>
> >>> The first example to look at is the TrackbackHandler than's part of
> >>> CommunityServer 1.1. If you go to http://code.communityserver.org/ and
> >>> open 1.1/Blogs/Components/TrackbackHandler.cs you'll see the relevant
> >>> source code. The purpose of this handler is to track pingbacks made to
> >>> blog entries. Most blog engines will automatically send a pingback to
> >>> any linked posts. This means that blog engines must also have a way to
> >>> capture these pingbacks and record them. There's more or less a
> >>> standard between how the communication is supposed to happen, but each
> >>> blog engine is really on its own as far as implementation. Without
> >>> spending too much time in the code, we can see that the handler looks
> >>> for a number of POST parameters and creates the trackback based on
> >>> what's passed in.
> >>>
> >>> There's absolutely no reason why all of this couldn't be done using
> >>> an ASPX page. But as I've already mentioned, that would force the
> >>> entire ASPX page framework to be invoked. Additionally, this handler
> >>> doesn't even have a visual element - so a page doesn't make too
> >>> much sense.
> >>>
> >>> (you can look at the web.config to see how the handler's added).
> >>>
> >>> Another example is my open source AMF.NET project which makes it
> >>> possible for a Flash application to communicate with server-side
> >>> ASP.NET code. The AmfGetwayHandler deserializes the AMF input (AMF is a
> >>> proprietary binary protocol used by Flash), executes the right server
> >>> side .NET function and returns a serialized response. Again, a single
> >>> ASP.NET page could be used to accomplish the same thing, but then it
> >>> would be impossible to package AMF.NET as a single assembly.
> >>>
> >>> Another common example you'll run across is using HttpHandlers to
> >>> generate RSS feeds. Many applications will map "Rss.aspx" to an
> >>> HttpHandler which generates a XML feed.
> >>>
> >>>
> >>> Why not to use HttpHandlers
> >>>
> >>> The biggest and very significant drawback of HttpHandlers is that they
> >>> can only be used for extensions that are mapped to ASP.NET in IIS. It
> >>> might be great to create a file download counter for your .zip files
> >>> using an HttpHandler, but since IIS doesn't go through ASP.NET to
> >>> serve .zip files, it isn't going to work. One solution is to map
> >>> those extra extension to ASP.NET, but that might have undesirable side
> >>> effects and might not even be possible for you (many developers don't
> >>> have direct access to IIS). In this case, the only solution is to
> >>> create an ISAPI filter which is much more difficult. IIS 7 promises to
> >>> let us write ISAPI filters in .NET (or extend HttpHandlers beyond the
> >>> ASP.NET pipeline depending on how you look at it), but that's still a
> >>> ways away.
> >>>
> >>
> >>

> >
> >


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Some information for the one who decided to learn C++, and now wantsto learn at least a bit of C? Alexander C Programming 20 09-11-2010 01:04 AM
Learn the language before you learn the GUI. CoreyWhite C++ 1 03-31-2007 08:56 PM
newbie question: should I learn TKinter or skip it and learn more advanced toolkit? Porky Pig Jr Python 3 05-12-2004 08:58 AM
Re: httpHandlers path config limitation Simen ASP .Net 1 07-24-2003 08:42 PM
Using httpHandlers to allows access to mp3 files Richard Brookes ASP .Net 0 07-09-2003 11:43 AM



Advertisments