.NET Routing in Forms Application; what about these generic handlers?

In this short tutorial i’ll try to show you how to route webrequests to your generic handlers. This topic seems to be a little untouched on msdn, which is weird, because it’s very important to rewrite for example the url of images that you use on your website.

So instead of rendering html like http://yourcoolwebsite.com/imagehandler.ashx?id=10 in your image’s source tag you’ll want to have something like http://yoursweetwebsite.com/awesome.jpg .

.NET Routing allows you to do this very easily (it’s true!).

Here’s what you’ll want to do:

  1. create a class that implements the IHttpHandler interface
  2. create a class that implements the IRouteHandler interface
  3. do the inner plumbing (i’ll get to it don’t worry)
  4. reference your url format in the global.asax
  5. excelsior!

So instead of using an .ashx file we’ll just create an ordinary class:

.net routing to generic handler: the classes

So what we have here is both an httphandler class and the routehandler.

As you can see you can pretty much just copy the processrequest from your old generic handler to the new processrequest method of the httphandler.

The RouteHandler will basicly supply the needed request context to our HttpHandler, this is where we’ll get the parameter from; the id for example of the image to return. In the Generic Handler of old we used to get the value of the querystring from the httpcontext, this is ofcourse useless now because we need the value from our Route context.

Here’s where the publicly defined RequestContext comes in to play. As the request to the routehandler is being made we return our very own HttpHandler but first set the RequestContext. Now you’ll have all your Routing variables available within your HttpHandler.

As for the Global.asax you’ll want to add something like this :

routing to the httphandler in your global asax

As you can see, all requests that comply to this sort of route will be routed to our – very geekalicious – routehandler.

The ImageUrl can now be completed something like this: AvatarImage.ImageUrl = string.Format(“~/avatars/{0}-{1}.jpg”, “somename”, “someuniqueidentifiermaybe”);

So as usual, hope this helps someone! And i’ll be glad to hear about any mistakes or stupid thing i’ve said.

Posted in .NET, ASP.NET, Software. No Comments »

Uploading large files to a WCF Webservice

So you have your WCF Service all set up and now you want to allow users to upload – or download, big files to your webservice. This is perfectly possible using WCF, however you do need to adjust some of the settings in your custom wsHttpBinding.

Your service is by default configured not to be able to handle the larger transfers. This is simply to shield it from possible DOS attacks and other crap.

First of all i would like you to know how to make the transfer of your file as efficient as possible. By default your soap message is just text, if you use the default text encoding your transfer will be slow (yet very interopable).

Enter Mtom. Mtom stands for Soap Message Transfer Optimization Mechanism and this is basically designed to handle large binary messages. Advantages of MTOM are mostly that the transmitted data isn’t as bloated as is the data went sent in base64 encoding (33%!) and Mtom also is interopable; assuring other technologies to be able to use your sweet-ass webservice.

For this example i’ll use Mtom encoding because Mtom packs some cool advantages and provides the middle way; optimization and interoperability. If you do not care about interopability you should likely go for the Binary encoding.

So there’s 3 available encodings and you can find out all their advantages and disadvantages right here on msdn.

Here’s what MSDN says about Mtom:

The MTOM encoding transmits most XML in textual form, but optimizes large blocks of binary data by transmitting them as-is, without conversion to text. In terms of efficiency, among the encoders WCF provides, MTOM is in-between text (the slowest) and binary (the fastest).

Changing the message encoding alone wont get you any far though, you’ll still need to increase the size of message which your service is allowed to take in (or let out).

This you’ll configure in your custom binding as well; change the maxReceivedMessageSize to the desired size (i increased it to 8mb or 8.000.000 in my example).
In the readerQuotas section in your binding (you might need to add this yourself) you change the maxArrayLength to the same desired size. This simply allows the internal XML reader to take in this certain amount of data.

web.config of the Service adjusted to allow for large file transfers

web.config of the Service adjusted to allow for large file transfers

 

You are now almost ready!

Please make sure dat you also add under system.web in the httpRuntime “maxRequestLength” with as value your desired filesize. This allows IIS to process the filesize you please.
This bit is often let out of blogs and can cause you some headaches.

What msdn has to say about maxRequestLength:

Indicates the maximum file upload size supported by ASP.NET. This limit can be used to prevent denial of service attacks caused by users posting large files to the server. The size specified is in kilobytes. The default is 4096 KB (4 MB).

allowing IIS to crunch a request this large

If you will work with many simultaneously running file up- or download it will be worth a look at the streaming capacities of WCF (which i’ll not touch in this short demo).

Hope this is any help! Please let me know about all the things i’ve gotten wrong; i’m quite flawed.

Posted in .NET, Software, WCF. 1 Comment »