Points dans l'URL provoque une 404 avec ASP.NET mvc et IIS
J'ai un projet qui nécessite de mes URLs ont des points dans le chemin d'accès. Par exemple j'ai peut-être une URL de la forme www.example.com/people/michael.phelps
Url avec le point de générer une erreur 404. Mon routage est très bien. Si je passe dans michaelphelps, sans le point, puis tout fonctionne. Si j'ajoute le point j'ai une erreur 404. L'exemple de site est en cours d'exécution sur Windows 7 avec IIS8 Express. URLScan est pas en cours d'exécution.
J'ai essayé d'ajouter ce qui suit à mon web.config:
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
Malheureusement, ça ne fera pas de différence. Je viens de recevoir un 404.0 ne Trouve Pas d'erreur.
C'est un MVC4 projet, mais je ne pense pas que ce soit pertinent. Mon routage fonctionne très bien et les paramètres j'attends sont là, jusqu'à ce qu'ils comprennent un point.
Que dois-je configurer pour que je puisse avoir des points dans mon URL?
- Ne peux pas croire que j'ai passé autant de temps sur celui-ci. L'URL fonctionne très bien si j'ajoute un slash. Par exemple, www.example.com/people/michael.phelps/ cependant sans le slash IIS renvoie une erreur 404.
- Marque - c'est parce que sans le slash, IIS pense que c'est un fichier qu'il doit aller la chercher. L'ajout de la barre oblique a pour effet de...ce n'est pas un vrai fichier. En outre, l'option de configuration ci-dessous indique IIS qui, si elle n'est pas un fichier, essayez de route de la place.
- Je vais avoir le même problème, après j'ai mis à jour mon projet mvc 4 + asp.net 4.5.
- Comme je suis en utilisant IIS Réécrire pour ajouter le slash de fin de mon Url.
- Cela ne fonctionne pas pour moi. L'URL fonctionne très bien avec le "." dans l'URL, mais quand il est à la fin il donne une erreur
- Voulez-vous dire quand le '.' est le dernier caractère ou, tout simplement, le mot de la fin de l'URL?
- la période est en invoquant le gestionnaire de fichier statique. Ensemble runAllManagedModulesForAllRequests="true" dans le web.config et il va fonctionner.
Vous devez vous connecter pour publier un commentaire.
J'ai eu ce travail par l'édition de mon site HTTP gestionnaires. Pour mes besoins ce qui fonctionne bien et qui résout mon problème.
J'ai simplement ajouté un nouveau gestionnaire HTTP qui cherche un chemin spécifique critères. Si la demande correspond à ce qu'il soit correctement envoyé .NET pour le traitement. Je suis beaucoup plus heureux avec cette solution que le URLRewrite hack ou de l'activation RAMMFAR.
Par exemple d'avoir .NET le processus de l'URL http://www.example.com/people/michael.phelps ajoutez la ligne suivante à votre site web.config dans le
system.webServer /handlers
élément:Modifier
Il y a d'autres postes, ce qui suggère que la solution à ce problème est
RAMMFAR
ouRunAllManagedModulesForAllRequests
. L'activation de cette option permettra à tous les modules gérés pour toutes les demandes. Cela signifie que les fichiers statiques, tels que des images, des fichiers Pdf et tout le reste sera traité par .NET quand ils n'ont pas besoin de l'être. Cette option est préférable à gauche sauf si vous avez un cas spécifique pour elle.RouteExistingFiles
propriété dansRouteCollection
. Lorsque la valeur est false, il sera de retour de 500 pour demander si le chemin d'accès virtuel points de fichier réel, après la cartographie de chemin d'accès virtuel au physique.Après quelques farfouillé, j'ai trouvé que relaxedUrlToFileSystemMapping ne fonctionne pas du tout pour moi, ce qui a fonctionné dans mon cas a été mise en RAMMFAR à true, la même chose est valable pour (.net 4.0 + mvc3) et de (.net 4.5 + mvc4).
Être conscient lors de la configuration de RAMMFAR vrai , Hanselman post sur RAMMFAR et de la performance
Je crois que vous devez définir la propriété relaxedUrlToFileSystemMapping dans votre site web.config. Haack a écrit un article à ce sujet il y a peu (et il ya quelques autres AFIN de postes poser le même type de question)
Je suis coincé sur ce problème pendant une longue période après toutes les différentes voies de recours, sans succès.
J'ai remarqué que lors de l'ajout d'une barre oblique [/] à la fin de l'URL contenant les points de suspension [.], il n'a pas une erreur 404 et elle a effectivement travaillé.
J'ai finalement résolu le problème en utilisant une URL rewriter comme IIS Réécriture d'URL à regarder pour un motif particulier et ajouter la formation slash.
L'adresse de ma page ressemble à ceci: /Contact/~prénom.lastname donc, mon patron est tout simplement: /Contact/~(.*[^/])$
J'ai eu cette idée de Scott Forsyth, voir le lien ci-dessous:
http://weblogs.asp.net/owscott/handing-mvc-paths-with-dots-in-the-path
Il suffit d'ajouter cette section Web.config, et toutes les demandes de la route/{*pathInfo} sera géré par le gestionnaire spécifié, même quand il y a des points dans le pathInfo. (prises de ServiceStack MVC Web Hôte.config exemple et cette réponse https://stackoverflow.com/a/12151501/801189)
Devrait fonctionner pour les deux IIS 6 & 7. Vous pourriez assigner des gestionnaires des chemins différents après la "route" en modifiant le chemin d'accès="*" dans "ajouter" éléments
MVC 5.0 solution de Contournement.
Beaucoup de réponses proposées ne semble pas fonctionner dans MVC 5.0.
Que la 404 dot problème dans la section précédente peut être résolu par la fermeture de cette section avec un slash de fin, voici la petite astuce que j'utilise, propre et simple.
Tout en gardant une pratique de l'espace réservé à votre avis:
ajouter un peu de jquery/javascript pour faire le travail:
veuillez noter que le slash de fin, qui est responsable de la modification de
en
Super facile de réponse pour ceux qui n'ont que cela à une page web. Modifier votre actionlink et a + "/" à la fin de celui-ci.
Vous voudrez peut-être penser à l'aide de tirets à la place de périodes.
Dans Pro ASP MVC 3 Cadre ils suggèrent ce sujet de faire des URLs:
Il mentionne également que les URLs doivent être faciles à lire et les modifier pour les humains. Peut-être une raison de penser à l'aide d'un tiret au lieu d'un point vient aussi du même livre:
Ainsi, alors que la période est toujours lisible pour les humains (bien que moins lisible que les tirets, de l'OMI), il pourrait encore être un peu confus/trompeuse selon ce qui vient après la période. Que faire si quelqu'un a un nom de famille de zip? Ensuite, l'URL sera /John.zip au lieu de /Jean-zip, quelque chose qui peut être trompeuse, même pour le développeur qui a écrit l'application.
.
) avec des tirets dans son utilisateur, url 😛En fonction de combien il est important pour vous de garder vos URI sans querystrings, vous pouvez aussi passer la valeur à l'aide de points dans le cadre de la chaîne de requête, pas de l'URI.
E. g. http://www.example.com/people?name=michael.phelps de travail, sans avoir à modifier les paramètres ou quoi que ce soit.
Vous perdez l'élégance d'avoir un propre URI, mais cette solution ne nécessite pas la modification ou l'ajout de tous les paramètres ou des gestionnaires.
Serait-il possible de changer de structure d'URL?
Pour ce que je travaillais, j'ai essayé un itinéraire pour
mais il a échoué avec tout ce qui avait un . en elle.
Je suis passé de la route à
Maintenant je peux mettre dans
localhost:xxxxx/File1.doc/Download
et il fonctionne très bien.Mes compagnons d'œuvre dans la vue aussi ramassé sur lui
qui fait un lien vers le
localhost:xxxxx/File1.doc/Download
format en tant que bien.Peut-être pourrais-tu mettre une inutiles mot comme "/view" ou l'action sur la fin de votre itinéraire de façon à ce que votre propriété peut fin avec un trailing
/
quelque chose comme/mike.smith/view
Essayé toutes les solutions ci-dessus, mais aucun d'entre eux travaillaient pour moi. Qu'avez-travail a je la désinstallation .NET versions > 4.5, y compris toutes ses versions multilingues; Finalement, j'ai ajouté plus récentes (en anglais seulement) versions pièce par pièce. Droit maintenant des versions installé sur mon système est: est-ce
Et de ses travaille encore à ce point. J'ai peur d'installer 4.6.2 car il peut gâcher tout le haut.
Donc je ne pouvais penser qu'4.6.2 ou toutes ces versions non anglaises ont été gâcher ma configuration.
HTH quelqu'un.
C'est aussi simple que de changer de chemin d'accès="." path="". Il suffit de retirer le point dans le chemin d'accès pour ExensionlessUrlHandler-Intégré-4.0 dans le web.config.
Voici un bel article https://weblog.west-wind.com/posts/2015/Nov/13/Serving-URLs-with-File-Extensions-in-an-ASPNET-MVC-Application
J'ai pu résoudre mon version particulière de ce problème (dû faire /customer.html route pour le client, barres obliques ne sont pas permis) à l'aide de la solution à https://stackoverflow.com/a/13082446/1454265, et la substitution de chemin d'accès="*.code html".
Comme solution pourrait être, compte tenu également de l'encodage dans un format qui ne contient pas de symbole
.
, en base64.En js doit être ajouté
Dans le contrôleur
Ajouter de la règle de Réécriture d'URL sur le Web.config archive. Vous avez besoin d'avoir le Module de Réécriture d'URL déjà installé dans IIS. Utiliser la règle de réécriture suivante comme source d'inspiration pour votre propre.
Aussi, (relative) par chèque à l'ordre de votre mappages de gestionnaires. Nous avons eu une .ashx avec un .svc (par exemple, /foo.asmx/bar.svc/chemin d'accès) dans le chemin d'accès d'après elle. L' .svc cartographie a été en premier afin de 404 pour le .svc chemin qui les a mis devant le .asmx.
Havn pas trop pensé mais peut-être url encodeing le chemin d'en prendre soin.