Poor-Man’s ISAPI Filter

joshpoley — Mon, 18 Feb 2008 20:39:00 GMT

On IIS, writing an ISAPI filter can give you flexible control over the URL path which users pass into your site. For example, normally when a user tries to hit http://server/path1/path2/filename, the virtual path must exist in some form on the server’s file system in order for the web server to resolve the page. But when using an ISAPI filter, you can remove this restriction and use the path as just another input into your application. So on the above URL, path1/path2/filename may not exist at all and are just used as a parameter to your ISAPI application to determine what content to serve back to the customer. This comes in handy when you want to provide easy to understand/remember URLs to your users but maintain the dynamic nature of handling diverse results from one application.

The bad news is that writing and debugging a full blown ISAPI filter is often more work than is warranted for a small internal tool. The good news is that we can accomplish the same effect using old school ASP scripts and a custom 404-error page. This also works well if you are on a server or ISP which doesn't allow you to run custom ISAPI applications (but does give you control of 404 errors).

For the sake of an example, let’s assume that you are setting up a web site to display test results. It would be easier on the users (including non-technical managers) if the components being tested were organized in a tree structure and this was then represented back in the URL path, so a shortcut may take the form “http://server/testresults/UI/dialogFoo”. If we setup a custom 404-error page for this “testresults” site we can give the user the ability to utilize this free-form and dynamic URL.

Setting up a custom 404 error page is extremely easy, we just need to go into the site properties and under the "Custom Errors" tab we modify the 404 error to point the URL at our own ASP page ("/testresults/404.asp" in this case).

Let's take a look at a simple 404.asp page which we create and add to the site:

<HTML>

<BODY>

<H1>Custom 404 Page</H1>

<%=Request.ServerVariables("QUERY_STRING")%>

</BODY>

</HTML>

Now let us go to testresults/test.asp (which doesn't exist) in a web browser and we will get an output like this:

Custom 404 Page

404;http://server/ testresults/test.asp

You will notice that the URL which the user attempted to access is just passed in as a parameter via the query string. So now it is just a matter of parsing this value to determine what content the user is interested in so you can provide a more meaningful response.

Since we are returning valid data it would be good of us to return a successful status code back to the browser (in the response HTTP header). On the other hand, just don’t forget to provide a code path to return a real 404 error if what the user is looking for truly doesn’t exist.

<% Response.Status = "200 OK" %>

<% Response.Status = "404 File not found" %>

In the failure case, it would also be nice of you to provide links to possible locations based on the input URL.

Serving iCalendar from ASP

joshpoley — Wed, 12 Dec 2007 19:19:00 GMT

As a follow up to the previous post (http://blogs.msdn.com/joshpoley/archive/2007/12/10/creating-calendar-items.aspx), we will show how to serve up custom iCalendar files via an IIS web server.

The first thing to do is configure IIS to associate the .ICS file extension with the ASP script engine. This will allow us to create dynamic iCalendar files using our favorite scripting language. From the "Application Configuration" page (which is accessible from the web site's properties screen: on the "Home Directory" tab click on the "Configuration…" button) we can add a new file extension and associate it with asp.dll:

Now, when a user attempts to load up an .ics file, asp.dll will parse it first looking for script blocks. This gives us the ability to pass in arguments (such as the time and subject) and do any other processing we need.

event.ics

<%@ Language=JavaScript EnableSessionState=False%>

Response.ContentType = "text/calendar";

BEGIN:VCALENDAR

VERSION:2.0

PRODID:Serving iCalendar from ASP, Josh Poley

BEGIN:VEVENT

SUMMARY:<%=Request("s")%>

DTSTART;TZID=US-Pacific:<%=Request("start")%>

DTEND;TZID=US-Pacific:<%=Request("end")%>

BEGIN:VALARM

TRIGGER:-PT15M

ACTION:DISPLAY

END:VALARM

END:VEVENT

END:VCALENDAR

In the above sample, we first set the language to JavaScript (which is just a personal preference) and then disable "session state" cookies as we don't need them. The important statement is where we set the ContentType (which is the MIME specifier for the data we are creating). This helps inform the web browser how to interpret the file: we don't want the browser to just display the text; instead it should pass it off to the operating system to handle (which typically results in an "open or save" dialog popping up).

We then take 3 inputs and use them to generate the iCalendar properties. So with the above code, if I hit the following URL in a web browser:

event.ics?s=test%20it!&start=20071212T140000&end=20071212T150000

I will receive a calendar entry for 2-3pm on December 12^th with the subject of "test it!"

Since we are within a scripting environment, we can also go in and add some more interesting logic, such as providing a default end time if none is supplied (for example, one hour from the start time), or use today's date if no date information is passed in… but, I will leave that as an exercise for the reader.

As an aside, this same mechanism can be used to generate a varying degree of content. For example, I’ve used it to generate custom bug queries on the fly, allowing users to just click on a URL to open up a specific bug in our tracking tool (the bug’s ID is the parameter passed into the ASP processor).

Software Sleuthing : Web Tools

Poor-Man’s ISAPI Filter

Serving iCalendar from ASP