HTTP handlers - Maintaining global objects, and multi-threading

  • Thread starter Thread starter Chris Hughes
  • Start date Start date
C

Chris Hughes

I have an environment with many thousands of client machines uploading
data files several times each day to a web server via HTTP PUT.

To avoid disk I/O (for performance), I am implementing a HTTP handler
to intercept and process incoming data without touching the disk. I
cannot detect PUT requests with my handler (don't know if this is even
supported), so I'm redirecting all requests to the handler as POST
using an ISAPI filter.

I wish to share LDAP and SQL connections across multiple requests (for
performance). Is it possible to maintain global objects in a HTTP
handler (equivalent to global.asax in web applications)?

Files are uploaded through a tree hierarchy, and at the top-level only
a handful of machines upload the files to the topmost web server. I
have no control over these machines, which upload files one at a time.
So I need a way to complete the HTTP request (so the next file can
begin uploading), before the content has been processed. If I create a
new thread from ProcessRequest() to do the processing, and return from
ProcessRequest(), will this:
a) Terminate the new thread - bad
b) Trigger the next HTTP request, but keep the new thread running
c) Wait for the new thread to terminate before triggering the next
HTTP request

Any help is greatly appreciated.

Cheers,
Chris Hughes
 
System.Web.UI.Page is the default HttpHandler for ASP.Net. When you create
an HttpHandler, you are substituting your class for the Page class as the
handler for the request types you specify. As such, you certainly do have
access to all the elements that System.Web.UI.Page has access to, as your
Handler is also running under ASP.Net, and works within the same HttpContext
that a Page class does. In fact, you can use a global.asax file in your app
as well, and access the Application, Cache, and Session, just as you would
with a Page.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Neither a follower nor a lender be.
 
Chris Hughes said:
I have an environment with many thousands of client machines uploading
data files several times each day to a web server via HTTP PUT.

To avoid disk I/O (for performance), I am implementing a HTTP handler
to intercept and process incoming data without touching the disk. I
cannot detect PUT requests with my handler (don't know if this is even
supported), so I'm redirecting all requests to the handler as POST
using an ISAPI filter.
Click to expand...

I don't know why you wouldn't be able to get PUT requests. Did you specify
PUT as a verb in the said:
I wish to share LDAP and SQL connections across multiple requests (for
performance). Is it possible to maintain global objects in a HTTP
handler (equivalent to global.asax in web applications)?
Click to expand...

Sure. Just keep the globals in static (Shared in VB) class members. But
you'll have to synchronize access to them, of course. "lock
(typeof(MyHandler))" should do it.
Files are uploaded through a tree hierarchy, and at the top-level only
a handful of machines upload the files to the topmost web server. I
have no control over these machines, which upload files one at a time.
So I need a way to complete the HTTP request (so the next file can
begin uploading), before the content has been processed.
Click to expand...

It sounds like you need an asynchronous HTTP Handler. Look up
IHttpAsyncHandler in the documentation.
 
Thanks for the feedback, John. Very helpful.
I don't know why you wouldn't be able to get PUT requests. Did you specify
PUT as a verb in the <httpHandler> element in web.config?
Click to expand...

I set verb="*". I did some searching, and machine.config configures
only HttpGet, HttpPost and HttpSoap requests by default. The
documentation states that this is not extensible for now.

I was told by a Microsoft rep that I can access the data through an
ISAPI extension by using an ISAPI filter to change the HTTP header
from PUT to POST. However, my testing has found that an HTTP handler
does not recognise these changes, and that I might need to use an
ISAPI extension instead, which would be unfortunate.

Any ideas how I might get around this? Is the HTTP handler loaded
before the ISAPI filter is able to change the HTTP header?

Cheers,
Chris Hughes
 
Chris Hughes said:
Thanks for the feedback, John. Very helpful.


I set verb="*". I did some searching, and machine.config configures
only HttpGet, HttpPost and HttpSoap requests by default. The
documentation states that this is not extensible for now.
Click to expand...

You may have misunderstood. "HttpPost" has to do with Web Services. verb="*"
should work. Give it a try. You'll also have to configure IIS to pass that
verb to your handler. Click "Configuration" on the Home Directory tab.
 
John,
You may have misunderstood. "HttpPost" has to do with
Web Services. verb="*" should work. Give it a try. You'll
also have to configure IIS to pass that verb to your
handler. Click "Configuration" on the Home Directory tab.
Click to expand...

This is perfect. I don't have to write any ISAPI dlls. I have tested
your suggestions, and they work great!

Thanks again.

Cheers,
Chris Hughes
 
Back
Top