Réécriture d'URL avec UrlRewritingNet échoue avec un char + dans l'URL

Question

J'utilise UrlRewritingNet dans Umbraco pour faire une URL de base de réécriture des produits et URL catégorie. Tout est bien sur ma machine locale (dev-webserver Visual Studio) et sur notre serveur de développement interne (Windows Server 2008 avec ISS 7, 32 bits). Mais il échoue sur le serveur de production, qui est Windows Server 2008 R2 avec IIS 7 (64 bits). Le symptôme est que la règle de réécriture ne se déclenche pas. Le serveur me donne simplement une erreur 404.

Le regard des règles de réécriture comme ceci:

<add name="CategoryRewrite"
     virtualUrl="^/products/(.*)/(.*).aspx"
     rewriteUrlParameter="ExcludeFromClientQueryString"
     destinationUrl="~/default.aspx?umbPage=1&amp;maincategory=$1&amp;subcategory=$2"
     ignoreCase="true"/>

Les regards d'URL comme suit - cela ne fonctionne pas:

http://example.net/products/category+name/sub+category.aspx

Si je change l'URL à ce qui suit cela fonctionne dans tous les 3 environnements:

http://example.net/products/category%20name/sub%20category.aspx

Il est clair que l'expression rationnelle dans l'attribut virtualUrl échoue lorsque le + est utilisé pour le caractère d'espace. Mais je dois admettre que je peux comprendre pourquoi le regex échoue uniquement sur le serveur Windows 2008 R2.

Je cherche des idées sur ce que les différences entre Windows Server 2008 R2 et les 2 autres environnements. Que dois-je rechercher?

Je confirme que la System.Web.RegularExpressions.dll est la même version sur les serveurs.

Answer 1

Le problème est que le filtre de requête de IIS7 rejette les URL contenant des caractères +. La solution est d'ajouter le suivant vous Web.config:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering allowDoubleEscaping="true" />
  </security>
 </system.webServer>
</configuration> 

Pour plus de détails: http: //blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx

Un collègue de travail a eu l'idée de brillant pour exécuter le site sur son propre IIS. Et puis l'erreur a été défini plus comme 404,11, et à partir de là une solution était simple.

Answer 2

Cela me semble étrange parce que votre regex correspond également à « + » caractères. Peut-être que le problème est dû au fait du premier caractère dans l'expression régulière, début de la chaîne « ^ » que vous utilisez. Peut-être que sur le serveur de production, vous obtenez une URL absolue et sur votre environnement de dev serveur une URL relative inséré dans le module de réécriture.