Installation is the same as for the full version.

Download Trial version and sample project (4MB)

When you upgrade to the full version, remember to delete the imagecache directory, or you will continue to see the word “Unlicensed” on old pictures.

So why am I writing another?

Because each article I have read includes one of the errors below, leading readers to write either
slow, insecure, or incorrectly functioning code. I have discovered many of these pitfalls the hard way.
I hope others won’t have to.

Instead of giving step-by-step instructions, this article will simply list pitfalls and the alternatives. I hope to publish my approach in a Part 2.

Security and Performance Pitfalls

1. Not using using(){}. You *must* wrap your Graphics, Bitmap, and MemoryStream objects
   in a using(){} clause, or else they will not get cleaned out of memory for a while.
   Under load this can cause *serious* issues. Read
   
   to dispose, or not to dispose, that’s the 1GB question if you have
   any doubts regarding the severity of this error.

   If you find yourself nesting a lot of using(){} statements, you can also use equivalent try{}finally{} code.

   //Using method. object must implement IDisposable for this to work
   using (object a = new object())
   {
       using (object b = new object())
       {
           using (object c = new object())
           {
   
           }
       }
   }
   
   //Try finally method
   object a = null;
   object b = null;
   object c = null;
   try
   {
       a = new object();
       b = new object();
       c = new object();
   }
   finally
   {
       if (a != null) a.Dispose(); //If one of the Dispose methods throws an error, the others will not execute.
       if (b != null) b.Dispose(); //So there is an advantage to using nested using(){} clauses
       if (c != null) c.Dispose(); //You could nest try{} finally{ try{} finally{ try{} finally{}}} to solve that...
       //Two different techniques - take your pick
   }
   

2. Using on-the-fly image resizing without disk caching! The ASP.NET
   memory cache won’t cut it here folks – it gets cleaned out every application reboot,
   and besides, you probably have more images than RAM. Resizing an image is fast,
   but it will still flood the CPU if a single user browses a single page with 20 or more
   resized images on it. This is a do-it-yourself
   DOS attack. On-the-fly resizing is fine if you have disk caching.
3. Not using on-the-fly resizing. This one bites also. If you decide to convert all
   your images up-front, please realize how difficult it will be to track down the
   originals and resizing them again next time you make a resolution jump. I’ve been
   through this enough, and it’s painful – that’s why I wrote a dynamic image resizer!
4. Disk-caching without checking for updated (or reverted!) source files. Debugging
   a resized image that won’t update can eat up lots of time. Make sure you set the
   LastWriteTimeUTC on your cached images to match the source image file (and check
   they match) – don’t simply check to see if the source file is newer than the cached
   file, since that will break if you copy an older file over a source image. Always
   use something like RoughCompare() to compare filesystem dates – *never* inequalities.
   Remember that filesystem dates are less precise than DateTime, and get rounded.

   /// <summary>
   /// Returns true if both dates are equal (to the nearest 200th of a second)
   /// </summary>
   /// <param name="modifiedOn"></param>
   /// <param name="dateTime"></param>
   /// <returns></returns>
   private static bool RoughCompare(DateTime d1, DateTime d2)
   {
   	return (new TimeSpan((long)Math.Abs(d1.Ticks - d2.Ticks)).Milliseconds <= 5);
   }
   

5. Disk-caching without cleanup! Another do-it-yourself
   DOS attack, although not quite as bad as the first. Left unchecked, your cache
   directory could grow very large over a few years as orphaned
   image versions accumulate. If a malicious visitor realizes that you have automatic resizing,
   he could try to fill up your hard drive by requesting an endless variety of resolutions
   for a given image. Of course, security-conscious developers will have cache-limiting
   systems in place. I suggest cleaning out the least recently used 10-20% of the cache
   directory whenever the file limit is reached. Handle locked files gracefully.
6. Checking the cache size for cleanup every image request. This will swamp your I/O.
   Instead of running that directory listing each time, keep a static counter that tracks how many new images have been resized
   since the application started. Run the cache cleanup on the first image request and each time the counter passes the cleanup threshold.
7. Disk caching without protecting the cache directory. Unless you want anonymous users to potentially view the same images
   as authorized users, you need your cache directory locked down. A Web.config file in the directory can do this – just verify your URL rewriting rules
   don’t leave another way to access the directory.

   The cache directory needs to stay inside the application to permit request rewriting to the cached files.

8. Disk caching without proper locking code. This is a minor problem, since the
   consequences are light – but it is good to remember that 2 image requests for the
   same image size could happen at the same time, and (if they aren’t cached), they
   may conflict when trying to write to the same file at the same time. You’ll probably
   get a “The process cannot access the file because it is being used by another process.”
   message if this happens. You can prevent this by creating a locking system so that
   only one thread can save a give resized image at a time. Optimally, you want multiple resizes for different images to occur at the same time. If you’re
   not as concerned about concurrency performance as I was, you could cheat at make the whole resizing method locked. (For new image requests only!)
9. Writing directly to the output stream. If you’re caching to disk, but still serving
   the image contents in code, you’re only supporting a little bit of the HTTP standard,
   and you’re bypassing all of the work Thomas
   Marquardt did to bring StaticFileHandler up to snuff . Implement your resizer
   as and HttpModule, not an HttpHandler or you’re stuck.
10. Serving a file from disk by loading it into memory. Think about how much RAM your server has,
    how large a single image is, how long
    it has to stay in memory before users finish downloading it, and how many users
    you have requesting images. Don’t load anything into memory after the initial resize.

    WriteFile()
    serves directly from disk, and is *much* safer and more efficient. However – you
    shouldn’t be using WriteFile() either if you can avoid it. Letting StaticFileHandler
    do its job is a much better choice.

11. Making an HttpHandler instead of an HttpModule. I actually did this in
    v1.0, and it was a *mess*, as well as being non-optimal from a performance standpoint.
    There are several problems with doing this as an HttpHandler.
    1. It’s very difficult to make an HttpHandler catch only *some* requests (i.e., those
       requesting resizing), for a certain extension. It’s very hard, in fact, and involves
       subclassing DefaultHttpHandler and re-implementing a lot of code. While that’s possible
       on IIS5/6/7 classic, it doesn’t work on IIS7 Integrated. So IIS7 integrated is a
       complete deal-breaker if you want to let standard images alone.
    2. It’s difficult to pass a request from one HttpHandler to another. When building
       an image resizer, we don’t want to be responsible for serving the resized file,
       just making sure the resized version has been cached to disk, and then rewriting
       the request to point to that file. An HttpModule, on the other hand, is perfectly
       suited to checking for image resize requests, caching the results, and rewriting
       the request so StaticFileHandler or whatever is the default in IIS 8 , 9, or 10
       can take of it. I do this in PostAuthorizeRequest, by calling context.RewritePath(virtualPath, false);
12. Not setting context.Response.ContentType properly. You’ll get all kinds of interesting,
    varied, and peculiar results from browsers if you omit this step. Things can be really
    interesting if the format is changed during the resize, since the extension will
    match the original format.
13. Obvious, but you should have caching enabled for your images, regardless
    of whether they are being resized or not. Disk caching is great, but memory caching allows for even faster responses to frequently requested images, and shouldn’t be omitted.
    In addition, HttpCacheability.Public enables client and proxy caching too, so browsers and some firewalls will cache the result from the server. You can adjust the amount of time
    the files are cached with SetExpires.

    This is the code I use during PreSendRequestHeaders

    HttpApplication app = sender as HttpApplication;
    HttpContext context = (app != null) ? app.Context : null;
    
    if (context != null && context.Items != null && context.Items["FinalContentType"] != null && context.Items["FinalCachedFile"] != null)
    {
    	//Clear previous output
    	//context.Response.Clear();
    	context.Response.ContentType = context.Items["FinalContentType"].ToString(); //FinalContentType is set to image/jpeg or whatever the image mime-type is earlier in code.
    	//Add caching headers
    	context.Response.AddFileDependency(context.Items["FinalCachedFile"].ToString());
    
    	if (context.Items["ContentExpires"] != null)
    		context.Response.Cache.SetExpires((DateTime)context.Items["ContentExpires"]); //ContentExpires is set to DateTime.Now.AddMinutes(x), where x is how long the clients should locally cache the image before checking for updates.
    
    	//Enables in-memory caching
    	context.Response.Cache.SetCacheability(HttpCacheability.Public);
    	context.Response.Cache.SetLastModifiedFromFileDependencies();
    	context.Response.Cache.SetValidUntilExpires(false);
    }
    

14. Accepting the file path as a querystring parameter. This mistake makes me cringe
    – I find it amazing each time how much people trust their filtering code to prevent
    abuse of this feature. (If they have path filtering code at all!) Just… don’t…
    do it… please. Do you know how many ways there are to encode filenames and circumvent
    pattern-matching techniques? Yes, there are ways to protect this kind of system, but why?

    Why choose /resizeimage.ashx?path=~%2fimg%2fproducts%2fbox.jpg&maxwidth=100&maxheight=100
    over /img/products/box.jpg?maxwidth=100&maxheight=100 ?

    If you’re stuck in IIS6 and you aren’t allowed to modify handler mappings, you should look for a better host.

Pitfalls in Image Resizing

1. Using GetThumbnailImage().
   GetThumbnailImage() seems the obvious choice, and many articles recommend its
   use.
   Unfortunately, it always grabs the embedded jpeg thumbnail if present.
   Some photos have these, some don’t – it usually depends on your camera. You’ll wonder
   why GetThumbnailImage works good on some photo, but on others is horribly
   blurred. GetThumbnailImage() isn’t reliable for photos larger than 10px by 10px for that reason.
2. Forgetting to set InterpolationMode, SmoothingMode, CompositingQuality, and PixelOffsetMode.
   With all these set properly, you
   should be able to get resized images indistinguishable from Photoshop results. If
   you don’t, you’ll end up with trash. GDI has dumb defaults. (BTW, the low-quality
   settings aren’t always much faster)
   This article explains why those are needed to make DrawImage compose the
   image well.

   graphics.InterpolationMode = InterpolationMode.HighQualityBicubic;
   graphics.SmoothingMode  = SmoothingMode.HighQuality;
   graphics.CompositingQuality = CompositingQuality.HighQuality;
   graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;
               

3. Not maintaining aspect ratio. I see this often, and I’m not sure why – the math
   isn’t too hard. Well, for those who are wondering how, I hope this code is rather
   transparent (no pun intended).

   double aspectRatio = imageWidth/imageHeight;
   double boxRatio = maxWidth/maxHeight;
   double scaleFactor = 0;
   if (boxRatio > aspectRatio)
    //Use height, since that is the most restrictive dimension of box.
    scaleFactor = maxHeight / imageHeight;
   else
    scaleFactor = maxWidth / imageWidth;
   
   double newWidth = imageWidth * scaleFactor;
   double newHeight = imageHeight * scaleFactor;
   

4. Not setting the Jpeg quality to 90. You’ll get huge Jpegs from Image.Save unless
   you pass in the proper parameters. 90 seems to be the magic value – great quality
   and much lower file size than 100.

   int quality = 90; //90 is the magic setting - really. It has excellent quality and file size.
   System.Drawing.Imaging.EncoderParameters encoderParameters = new System.Drawing.Imaging.EncoderParameters(1);
   encoderParameters.Param[0] = new System.Drawing.Imaging.EncoderParameter(System.Drawing.Imaging.Encoder.Quality, (long)quality);
   thumb.Save(stream, GetImageCodeInfo("image/jpeg"), encoderParameters);
   
   /// <summary>
   /// Returns the first ImageCodeInfo instance with the specified mime type. Some people try to get the ImageCodeInfo instance by index - sounds rather fragile to me.
   /// </summary>
   /// <param name="mimeType"></param>
   /// <returns></returns>
   public static ImageCodecInfo GetImageCodeInfo(string mimeType)
   {
   	ImageCodecInfo[] info = ImageCodecInfo.GetImageEncoders();
   	foreach (ImageCodecInfo ici in info)
   		if (ici.MimeType.Equals(mimeType, StringComparison.OrdinalIgnoreCase)) return ici;
   	return null;
   }
   

5. Using the built-in quantization (palette creation) for GIFs, 8-bit PNGs and BMPs.
   The default palette is truly terrible, and while you can specify your own set of
   255 colors – which ones should they be? The process of determining which colors
   to choose for the palette and to produce the best quality images is call quantization.
   I recommend the very efficient and decent-quality
   octree quantization algorithm. It does have a number of bugs you will have
   to patch. Follow the transparency patch instructions found in the comments. Use the safe version of the library. Patch the Marshal.ReadInt32() bug (original is ReadByte()).
   Change any casts from IntPtr->int to IntPtr->long to make the code 64-bit safe.

   I’m working on adding adjustable Floyd-Steinberg dithering to the version in my resizer , and
   the results have been very promising so far.

6. Inheriting the palette from the original image. While at first this seems like an
   
   easy way to solve the palette problem for GIFs, realize that the bicubic
   resizing will have combined colors, and the new thumbnail may not have any of colors
   of the original image. Also, any operations performed on the bitmap in 8-bit mode
   will be poor quality, and this won’t allow conversion between image formats. There are
   other ways to keep transparency. This is probably better than leaving the default palette, but YMMV.
7. Resizing images that don’t request it. Your code should only activate when an image has a querystring with one of the supported
   commands. Pushing all images through your code is unnecessary.
8. And one last piece of advice. Have Good Defaults. Always.

   The output image type should default to the source image type, unless it’s a BMP or TIFF.
   Default behavior should always preserve aspect ratio.

   Many developers stop after making their code configurable. They don’t take that extra 10 minutes to give
   everything smart defaults. Smart defaults distinguish good software from great software.

I hope to post Part 2 soon. I plan on revealing the architecture that has evolved in my resizer,
and how to design a IIS5/6/7 compatible HttpModule.

• When both ?width=x&height=y are specified, the default behavior has changed. Instead of stretching the image and losing aspect ratio, whitespace is added (controlled with &bgcolor=color name|code). You can reinstate the original behavor by adding &stretch=fill. Based on customer feedback.
• ICC profiles are now read on source images, but changes are merged into the image before output. Since most browsers (including Firefox) do not read ICC profiles, this should produce consistent cross-browser behavior. If you want to ignore the original ICC profile for an image, add &ignoreicc=true.
• The CustomFolders.cs format has changed, and is now much, much more powerful. All querystring commands can be used, and URL rewriting can be performed. (AllowURLRewriting must be true).

New features

Check out the samples page to see these features in action.

• Automatic cropping and centering can be performed with ?crop=auto&width=x&height=y. You can also choose a crop rectangle from the source image manually with &crop=(x1,y1,x2,y2). Negative values indicate distances relative to the bottom-right corner. (10,10,-10,-10) would crop a 10-pixel border off the source image.
• Support for 8-bit PNG file output with &colors=2-255. Sets the palette size for both PNG and GIF images.
• GIF and 8-bit PNG files are now much, much better. Instead of using the GDI default palette, octree quantization is used to calculate the optimal color palette for each image.
• Upscaling can be enabled using &scale=both. The default is &scale=downscaleonly. &scale=upscaleonly is also available for certain zooming situations.
• Image rotation is supported in degrees. Ex. &rotate=45. Image sizing is performed before rotation, so rotation will cause the final image size to be larger than the size specified in the querystring.
• Image flipping can be performed using &flip=h|v|both. To flip the source image before other commands occur, use &sourceFlip=h|v|both.
• BMP and TIFF source files are now supported.
• You can add padding around the image with &paddingWidth=px&paddingColor=color|hex. paddingColor defaults to bgcolor, which defaults to white.
• You can add a border around the image with &borderWidth=px&borderColor=color|hex.
• Transparency is maintained while resizng PNG files, and when converting from PNG to GIF.
• DisableCacheCleanup=true|false is now supported in Web.config. If you have plenty of disk space and wish to manually purge old files from the cache, this setting will allow it. Leave the default value to false unless you have a very good reason.
• DiskCacheAlwaysInvalid=true|false is a new Web.config setting for debugging. It forces every request to update the disk cache before responding. Very, very slow, so make *sure* this is false before you launch.
• Websites located on UNC paths are now supported. (Ex. \\server\share\website).

Installation

1. Replace the old files with the new files from the ImageResizer folder. If you are using the .DLL, replace the DLL in the bin folder. Keep a copy of your old CustomFolders.cs if you have modified it.
2. Delete the /imagecache directory.
3. If you use both width and height to stretch any images, add &stretch=fill to those URLs to maintain the same behavior.
4. Migrate CustomFolders.cs if you have modified it. The new file includes source comments explaining the process.

If you haven’t upgraded to 1.2, follow these instructions first

This integration isn’t valuable to most people, however, since they aren’t protecting any static files.
Users who don’t need this protection can enable the “AllowFolderResizeNotation” setting to gain additional URL flexibility in exchange.

Version 1.2 now passes *all* file serving work back to IIS. The cached image is now written to disk first rather than last, allowing a simple RewritePath call to handle the work.

The same code can now be used for both IIS5, 6, 7c and 7i. The httpModules section handles IIS5/6/7c, and the modules section handles IIS7 integrated mode.

<system.web>
  ...
  <httpModules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </httpModules>
  ...
</system.web>
<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  ...
  <modules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </modules>
</system.webServer>

Configuration

You will need to insert the following settings into web.config in the designated places.

<system.web>
  ...
  <httpModules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </httpModules>
  ...
</system.web>
<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  ...
  <modules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </modules>
</system.webServer>

Last, some app settings for the resizer. You can use the following safely with v2.1 and up. Full configuration reference and notes for other versions can be found in the next section.

<appSettings>
    ...
    <add key="ImageDiskCacheDir" value="imagecache" />
    <add key="MaxCachedImages" value="30000" />
    <add key="ImageResizerMaxWidth" value="1680" />
    <add key="ImageResizerMaxHeight" value="1680" />
    <add key="ImageResizerClientCacheMinutes" value="1440" />
    <add key="AllowURLRewriting" value="true" />
    <add key ="ResizeExtension" value=".axd"/>
    ...
</appSettings>

Complete reference

    <!-- The directory to store cached version of images. Relative to the application root -->
    <add key="ImageDiskCacheDir" value="imagecache" />  

    <!-- How many files to keep in the cache. The 10% least recently used files will be deleted
when this limit is reached. Don't set this lower than the number of images on your site. 2x the image count is a
 good default. If you are getting "Access Denied" messages, this is the cuplrit - you need to increase it -->
    <add key="MaxCachedImages" value="30000" />  

    <!-- The following settings are optional: -->  

    <!-- The maximum size to permit images to be resized to. -->
    <add key="ImageResizerMaxWidth" value="1680" />
    <add key="ImageResizerMaxHeight" value="1680" />  

    <!-- Takes effect in version 1.2. The default (for all versions) is 1440 minutes (24 hours).
        Set to 0 to disable *client* caching (304 "Not Modified" responses will still be returned
        if nothing has changed). Client caching is not related to disk caching. -->
    <add key="ImageResizerClientCacheMinutes" value="1440" />  

    <!-- This enables /resize(x,y,f)/image.jpg notation in v1.2+. Enabling this
      will make URL authorization ineffective on image files. Changed to AllowURLRewriting in 2.0-->
    <add key="AllowFolderResizeNotation" value="true" />  

    <!-- This enables /resize(x,y,f)/image.jpg notation and other CustomFolders.cs
rewriting (other than querystring-only changes) in v2.0. Enabling this
      will make URL authorization ineffective on image files on version prior to 2.1b.-->
    <add key="AllowURLRewriting" value="true" />  

    <!-- (v2.0a+ only) Prevents use of cached files - useful for development when changing resizing algorithms.
          Causes terrible performance - don't leave enabled.-->
        <add key="DiskCacheAlwaysInvalid" value="false"/>  

    <!-- (v2.0b+ only) Prevents the cache cleanup routine from running. If you want to
        manually purge the image cache yourself, and aren't worried about running out
        of disk space via a DOS attack, you can disable this. Not advised. -->
    <add key="DisableCacheCleanup" value="false"/>  

  <!-- (v2.1+ only) Disabling custom quantization allows the resizer to function in low trust
     environments where managed pointer access and data type marshaling is prohibited.
     However, PNGs and BMPs can only be output in 32-bit mode, and GIFs will use the default
     halftone pallete. Enable this if JPGs and PNGs work, but GIFs don't, and using colors=255
      on PNGs causes them to break also.
     Causes much lower quality GIFs to be generated.
      Version 2.1+.
    -->
    <add key ="DisableCustomQuantization" value="false"/>  

     <!-- (v2.1b+ only) This allows images to be resized without any IIS configuration whatsoever.
        Just set this value to ".axd", ".ashx", ".aspx", or any extension
        already registered in IIS, and add the same extension to your image URLs when you are resizing them.
    Doesn't conflict with other pages/files with that extension, unless you name them .jpeg.ashx., etc.

        Ex. /images/media/flower.jpg -> /images/media/flower.jpg.axd?width=x&height=y  

        AllowURLRewriting must be true.   

      Version 2.1b+.
    -->
    <add key ="ResizeExtension" value=".axd"/>

Server-side image resizing is one of those tiny features that can have incredible ROI. It can save webmasters several hours each day, and gives you the ability to change the resolution of an image without having to hunt up the original. However, many of the approaches currently on the web don’t take security or performance into account.

I developed this image resizing system about a year and a half ago. I wanted something very intuitive, simple, secure, and efficient. We’ve been using this system heavily on a live, high-traffic site (youngfoundations.org) for over a year, and we have had zero stability problems, memory leaks, or other issues with it. It’s very mature and stable.

Although I typically release my components for free, I decided to charge a ‘download fee’ for this one to help support my other open-source projects. Don’t worry, this component is still open-source, and the license permits source redistribution as part of a larger system. However, I’m asking that people who want to integrate this component purchase the download instead of ripping it out of another open-source project. My free to non-free LOC (lines of code) ratio is still over 40 to 1, and I plan on keeping it that way. I trust this will keep everybody happy.

Features

• Querystring-based resizing: image.jpg?width=100
  • ?format=jpg|png|gif — Changes the output format. (This was ‘thumbnail’ in v1.0).
  • &maxwidth=value&maxheight=value — Specify the maximum size for the resized image. Aspect ratio is maintained. You don’t have to use both maxwidth and maxheight – you can use just one.
  • &height=value&width=value — If used together, these will force the image to be stretched to the new dimensions. If height or width is used by itself, aspect ratio is maintained.
  • &quality=0-100 — Changes the jpeg compression setting. 90 is the default value, and you really don’t need to touch it. 90 produces fantastic quality and tiny files. New in v1.2
• Secure – images still have to pass through ASP.NET’s URL authorization system.
• Can be used from ASP, PHP, HTML files, or any language that runs alongside ASP.NET. Images are separate requests, so you don’t need to be using ASP.NET to make this work for you.
• Not just for thumbnails – can resize images to any resolution. You can set the size limitations in web.config.
• Great for slideshows – you can change the resolution of the images dynamically as the user resizes.
• Supported input formats: BMP, GIF, JPG, PNG and TIFF
• Supported output formats: JPG, PNG, GIF
• Photoshop-quality bicubic resizing and jpeg compression.
• Works with IIS5, IIS5.1, IIS6, IIS7, and ASP.NET 2.0+. v1.2 is optimized for IIS7 Integrated mode
• Well documented, well organized code.
• Great platform to build your own image processing systems on. You can use the disk caching system or image processing code separately.
• You can set entire folders of images to resize using CustomFolders.cs. (v1.2) You can do “URL rewriting” on your images there also.

Bonus functionality

• Example watermarking code. You can enable this feature by uncommenting the code.
• yrl class for dealing with virtual paths.

Performance

• Disk-based caching. Subsequent identical resizes are instantaneous.
  • Caching doesn’t get in your way – if you modify the source file, the resized versions are also updated.
  • You can resize the same image to several different sizes, and the different versions are cached separately.
  • Managed disk cache. If the number of cached files exceeds the configured threshold, a cleanup pass is made on the directory, and a block of the least recently used files are removed.
• Client-side caching directives are sent, minimizing repetitive requests from the same client.
• Thumbnail generation in under 20 milliseconds for most images.
• Suitable for slideshows and lists of images. Even the initial resizing of 50 images concurrently isn’t noticeably slow.
• Good with large source files (1-5MB)

Since we only want some .jpg requests to go to the handler, we need to do some logic before we assign a handler. In IIS 6 and IIS7 Classic Pipeline mode, we need to drop in a CustomDefaultHandler at the bottom of the httpHandlers list.

<httpHandlers>
      <clear/>
      <add path="trace.axd" verb="*" type="System.Web.Handlers.TraceHandler" validate="true"/>
      <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="true"/>
      <add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="true"/>
      <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="true"/>
      <add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="true"/>
      <add path="*.asmx" verb="*" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>
      <add path="*.rem" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
      <add path="*.soap" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
     <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>

<!-- These are forbidden extensions. I've added a lot here, such as .swp, .sln, .suo, .bak, and .db -->

<add path="*.asax" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.master" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.skin" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.browser" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.sitemap" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.dll.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="true"/>
      <add path="*.exe.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="true"/>
      <add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.csproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.vb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.vbproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.webinfo" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.licx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.resx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.resources" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.mdb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.vjsproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.java" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.jsl" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.ldb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.ad" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.dd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.ldd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.sd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.cd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.adprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.lddprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.sdm" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.sdmDocument" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.mdf" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.ldf" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.exclude" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.refresh" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.db" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
      <add path="*.bak" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
		<add path="*.swp" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
		<add path="*.sln" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
		<add path="*.suo" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>

		<add path="robots.txt" verb="*" type="System.Web.StaticFileHandler" validate="true"/>
<!-- I've also added .txt to prevent my todo files and readme files from being accessible. If you want to serve .txt files, remove this line -->
		<add path="*.txt" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>

      <add path="*" verb="GET,HEAD,POST" type="fbs.Handlers.CustomDefaultHandler" validate="true"/>
      <add path="*" verb="*" type="System.Web.HttpMethodNotAllowedHandler" validate="true"/>
    </httpHandlers>