Utilisation de Url.RouteUrl pour rediriger vers URL aveC#,%, etc.

Question

Dans une application Web sur laquelle nous travaillons, nous souhaitons pouvoir afficher des informations sur les ressources d'un chemin donné. Le chemin est entièrement virtuel — il n'existe que dans l'application — donc nous n'avons pas vraiment de problème avec les utilisateurs qui définissent des chemins virtuels qui sont "bizarres" par les standards du système de fichiers.

La question: nous avons une route qui lit quelque chose de similaire à

/Files/{*path} 

et nous essayons de rediriger avec

Url.RouteUrl("File", new { path = somePath }) 

Cela fonctionne habituellement, mais échoue si somepath contient & ou #, entre autres. Dans ces cas, je suis nul. Je ne peux pas UrlEncode(somePath) à ce stade, parce que RouteUrl fait son propre encodage d'URL, mais je ne peux pas les laisser tels quels, sinon ils ne sont pas traités correctement (l'octothorp n'est pas transmis aux données de routage, et le ampersand confond IIS). Y a-t-il une manière saine de contourner cela? Ou ai-je simplement besoin d'implémenter mes propres routes via une interpolation de chaîne?

Answer 1

J'ai joué avec votre exemple, et je ne trouve aucun problème avec l'utilisation de RouteUrl avec des caractères spéciaux comme décrit ci-dessus, du moins pas dans mes environnements de test. La méthode RouteUrl codifie les URL correctement, et le contrôleur obtient la valeur sous forme décodée sans problèmes ni déformations.

J'ai testé cela dans IIS 7 ainsi que sur le serveur Web de développement VS 2008.

Pouvez-vous fournir un exemple de code plus complet?

Answer 2

La meilleure réponse que j'ai trouvée jusqu'à présent, bien qu'elle ne fonctionne que sur IIS7, est de suivre les instructions du http://dirk.net/2008/06/09/ampersand-the-request-url-in-iis7/ pour éditer le registre et changer le comportement par défaut d'IIS7. Ceci est inacceptable pour nous, puisque nous faisons une application qui sera installée sur les machines de l'utilisateur final — et en tout cas, même si nous ne l'étions pas, il y aurait le simple fait que IIS6 et IIS5 ne répondent pas à cette séquence. Toutes les idées pour les versions antérieures d'IIS, ou les façons de remplacer ce comportement par programme dans IIS7, serait merveilleux.