IHttpHandler that handles all URL extensions in IIS 6, IIS 7 and ASP.NET Development Server

Question

We have a custom IHttpHandler that is responsible for file downloads. The handler is mapped to URL /downloadfile.rem

The browser redirects user to URL formatted like:
/downloadfile.rem/[fileID]/[mimeType]/[fileName].[extension]
example:
/downloadfile.rem/54923876129874545456621/text$plain/data.txt

Our handler gets the supplied information from the URL and responses with file data.

This method works in IIS 6 and IIS 7, but we have a problem with the ASP.NET Development Server. It seems, that IIS 6 and IIS 7 look at the URL from left to right and stop and the "downloadfile.rem" part and correctly invoke our custom handler. The ASP.NET Development Server seems to look and the URL from right to left and decides what to do with the file based on the extension at the end of the URL. This gives a 404 reponse. When we remove the extension from the end of the URL, everything works as expected.

This is our entry in httpHandlers section:

<add verb="GET" path="downloadfile.rem" type="OurNamespace.DownloadFileHandler"/>

This is our entry in handlers section:

<add name="DownloadFile" verb="GET" path="downloadfile.rem" type="OurNamespace.DownloadFileHandler"/>

How to make it work correctly in ASP.NET Development Server?

Rationale - why we do this the way we do it?
The files for download are generated dynamically as a result of an Ajax request. Since it is an Ajax request, we cannot return the file directly to the browser, but store it on the disk for the browser to request it later. The file name on the server side is the SHA-1 of the file contents (without extension).
We could simply make the browser send a GET request to a URL like
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
and on the server side return a Content-Disposition header with "attachment; filename=...", but there is a bug in a certain version of IE 6 (that we have to support), that ignores the filename part of the header and the user will be requested to save a downloadfile.rem file.
Therefore our URL must end with the filename that should be given to the file.

Answer 1

Well, I bet you never deploy such web application on a development server, do you?

I don't know if there is a way to configure that server not to verify the existence of a link (because this server finds your link does not point to a valid file on disk).

We can do that on IIS easily, however.