473,230 Members | 1,428 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,230 software developers and data experts.

HttpHandlers - Learn Them. Use Them.

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.

Jun 15 '06 #1
5 1970
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" <an******@hotmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro 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.

Jun 15 '06 #2
Good topic though, bookmarked :)


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:Ok**************@TK2MSFTNGP04.phx.gbl...
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" <an******@hotmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro 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.


Jun 16 '06 #3
6 - '.Fomrmat' and '.AppendFormat'

Oops :)

"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:Ok**************@TK2MSFTNGP04.phx.gbl...
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" <an******@hotmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro 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.


Jun 16 '06 #4
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" <ne**@hellobasic.com> schreef in bericht
news:44**********************@text.nova.planet.nl. ..
Good topic though, bookmarked :)


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:Ok**************@TK2MSFTNGP04.phx.gbl...
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" <an******@hotmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro 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.



Jun 16 '06 #5
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" <ne**@hellobasic.com> schreef in bericht
news:44**********************@text.nova.planet.nl. ..
Good topic though, bookmarked :)


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> schreef in bericht news:Ok**************@TK2MSFTNGP04.phx.gbl...
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" <an******@hotmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro 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.



Jun 16 '06 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: some guy with a computer | last post by:
I can not get a custom httpHandler to fire using machine.config and an assembly in the GAC. It will not work if I move the assembly to the GAC, even though I have it referenced correctly and add...
0
by: Chance Hopkins | last post by:
Does anyone know how to get a custom httpHandler to fire for all applications in machine.config for an assembly in the GAC, without using seperate location tags? For instance, this works for a...
1
by: Patrick Kristiansen | last post by:
Hi! I have on my website a root web.config file, and also created a subapplication "/publikationer". In my root web.config I've specified an HTTP-handler for some requests, but this is mirrored...
2
by: Prince | last post by:
I have the following code within the ASP.NET project I have created. public class RedirectHandler : IHttpHandler{ //empty constructor public void ProcessRequest(HttpContext context){...
4
by: Grant Harmeyer | last post by:
How would I set up an httpHandler so that it would only apply to certain child directories of the application? I.E: <httpHandlers> <add verb="*" path="/files/*/*/*/*.aspx"...
1
by: Steen Tøttrup | last post by:
This is what I'm doing: I'm using Httpmodules and Httphandlers to control access to files (images, movies, etc.), but have run into quite a problem when several files are being requested at the...
3
by: MWells | last post by:
I'm having an issue getting my HttpHandlers and HttpModules to play together nicely. My HttpHandlers take special document types (defined by extension) and process them specially. I might have...
0
by: tshad | last post by:
I have 2 controls that I need to run that I got of the Web. I have been using ScrollKeeper for awhile and was trying to add FreeTextBox to my site. But for some reason it won't run if ScrollKeeper...
1
by: hb | last post by:
I am trying to upload a site to godaddy. It works in my debug enviornment in VS2008, but not on the server. One of my problems is that when I add a custom httpHandler, it fails. E.g.: ...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.