IHttpHandler qui gère toutes les extensions d'URL dans IIS 6, IIS 7 et ASP.NET Development Server

Question

Nous avons un IHttpHandler personnalisé qui est responsable des téléchargements de fichiers. Le gestionnaire est mis en correspondance avec l'URL /downloadfile.rem

Le navigateur redirige l'utilisateur à l'URL formaté comme:
/downloadfile.rem/[fileID]/[mimeType]/[fileName].[extension]
exemple:
/downloadfile.rem/54923876129874545456621/text$plain/data.txt

Notre gestionnaire obtient les informations fournies à partir de l'URL et des réponses avec des données de fichier.

Cette méthode fonctionne dans IIS 6 et IIS 7, mais nous avons un problème avec le serveur de développement ASP.NET. Il semble que IIS 6 et IIS 7 regardent l'URL de gauche à droite et arrêtent la partie "downloadfile.rem" et invoquent correctement notre gestionnaire personnalisé. Le serveur de développement ASP.NET semble regarder et l'URL de droite à gauche et décide quoi faire avec le fichier basé sur l'extension à la fin de l'URL. Cela donne une réponse de 404. Lorsque nous supprimons l'extension de la fin de l'URL, tout fonctionne comme prévu.

C'est notre entrée dans la section httpHandlers:

< ajouter verb = "GET" path = type = "OurNamespace.DownloadFileHandler"/>

"de downloadfile.rem" Ceci est notre entrée dans la section des gestionnaires:

< add name = "DownloadFile" verb = chemin "GET" = type "downloadfile.rem" = "OurNamespace.DownloadFileHandle r "/ >

Comment faire fonctionner correctement dans ASP.NET Development Server?

Justification - pourquoi faisons-nous cela comme nous le faisons?
Les fichiers à télécharger sont générés dynamiquement à la suite d'une requête Ajax. Comme il s'agit d'une requête Ajax, nous ne pouvons pas renvoyer le fichier directement au navigateur, mais le stocker sur le disque pour que le navigateur le demande plus tard. Le nom du fichier côté serveur est le SHA-1 du contenu du fichier (sans extension).
Nous pourrions simplement rendre le navigateur envoyer une requête GET à une URL comme
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
et le retour sur le côté serveur un Content-Disposition header avec "attachment; filename = ...", mais il y a un bug dans une certaine version d'IE 6 (que nous devons supporter), qui ignore la partie filename de l'en-tête et l'utilisateur sera invité à sauvegarder un fichier de téléchargement Fichier .rem.
Par conséquent, notre URL doit se terminer par le nom de fichier qui doit être donné au fichier.

Answer 1

Eh bien, je parie que vous ne déployez jamais une telle application web sur un serveur de développement, n'est-ce pas?

Je ne sais pas s'il y a un moyen de configurer ce serveur de ne pas vérifier l'existence d'un lien (parce que ce serveur trouve votre lien ne pointe pas vers un fichier valide sur le disque).

Nous pouvons le faire sur IIS facilement, cependant.