Route contenant <space> et slash

Question

Nous avions un itinéraire défini comme

routes.MapRoute(
      name: "SearchFor", 
      url: "Search/For/{text}", 
      defaults: new 
      { 
       controller = "Search", 
       action = "For", 
       text = UrlParameter.Optional 
      } 

Après un nouveau client dont les données pouvait contenir beaucoup de slashs nous avons eu un problème avec text tels que item/1. Pour contourner ce la route a été mis à jour comprennent un fourre-tout comme suit

routes.MapRoute(
      name: "SearchFor", 
      url: "Search/For/{*text}", 
      defaults: new 
      { 
       controller = "Search", 
       action = "For", 
       text = UrlParameter.Optional 
      } 

Toutefois, cela ne permet pas si le text contient un espace de premier plan à la barre oblique par exemple item /1 qui provoque IIS pour renvoyer une erreur 404.

Est-il possible de contourner ce problème sans coder le paramètre de texte d'une certaine manière?

Answer 1

Les espaces (et la plupart des autres caractères spéciaux) doivent être codés en URL afin d'être utilisés dans le chemin des URL. Cependant, ceci est une mauvaise pratique et devrait être évitée. Voir (Please) Stop Using Unsafe Characters in URLs.

Une meilleure approche consiste à utiliser la chaîne de requête en combinaison avec le codage d'URL pour les caractères dangereux.

routes.MapRoute(
     name: "SearchFor", 
     url: "Search", 
     defaults: new 
     { 
      controller = "Search", 
      action = "For" 
     } 

Et utilisé comme ...

/search?text=Some%20Text 

Certains pare-feu et serveurs n'interprètent pas correctement les informations codées URL lorsqu'elle fait partie du chemin, mais les informations de chaîne de requête est plus fiable. Sans parler des problèmes de sécurité mentionnés dans l'article ci-dessus.

Sinon, vous pouvez concevoir votre URL pour remplacer les caractères dangereux pour ceux sûrs ...

/search/for/some-text 

... mais cela prendra plus de considération pour couvrir tous les cas particuliers pour votre cas d'utilisation particulière. Essentiellement, votre application doit être assez intelligente pour convertir les caractères sécurisés vers et à partir des caractères dangereux. Mais, quelle que soit la solution, les URL sont avant tout rendues lisibles par machine et vous devez en tenir compte lors de leur conception.