Page HTTP 404 introuvable dans Web Api hébergée dans IIS 7.5
J'ai une application Web Api. Cela fonctionne parfaitement bien lorsque je l’ai testé avec le serveur de débogage VS 2010. Mais je l'ai maintenant déployé sur IIS 7.5 et j'obtiens une erreur HTTP 404 lorsque j'essaie d'accéder à l'application.
Voici mon web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-FlowGearProxy-20123141219;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
<add key="webpages:Version" value="2.0.0.0" />
<add key="webpages:Enabled" value="true" />
<add key="PreserveLoginUrl" value="true" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
</appSettings>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="2880" />
</authentication>
<pages>
<namespaces>
<add namespace="System.Web.Helpers" />
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="System.Web.WebPages" />
</namespaces>
</pages>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
Je me débattais aussi avec ça. Heureusement, Steve Michelotti a documenté une solution qui a fonctionné pour moi ici .
À la fin de la journée, j'ai activé tous les verbes (verb = "*") du gestionnaire ExtensionlessUrlHandler-Integrated-4.0 dans ma configuration Web.
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
D'autres ont souligné qu'avoir WebDAV activé posait des problèmes. Heureusement, je n'ai pas rencontré ce problème non plus.
J'ai eu le même problème. Ce paramètre de configuration a résolu le problème.
<system.webServer>
.....
<modules runAllManagedModulesForAllRequests="true" />
.....
</system.webServer>
Comme expliqué dans la solution http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html above doit être évité. Utilisez ceci à la place. La même solution est fournie par Lopsided également. Conservez-le ici pour permettre aux utilisateurs d'éviter d'implémenter la première solution opérationnelle.
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
<!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>
Si IIS est installé ou activé après ASP.NET, vous devez enregistrer manuellement ASP.NET avec IIS pour que votre application .NET fonctionne.
Pour Windows 7 et les versions antérieures:
- Exécutez l'invite de commande (cmd.exe) en tant qu'administrateur.
- Accédez à l'emplacement approprié .NET Framework. (par exemple, C:\Windows\Microsoft.NET\Framework64\v4.0.30319)
- Exécutez aspnet_regiis.exe -i
Pour Windows 8 et versions ultérieures:
- Dans le menu Démarrer, tapez "Activer ou désactiver les fonctionnalités de Windows" et sélectionnez le premier résultat.
- Développez Internet Information Services: Services World Wide Web: Fonctionnalités de développement d'applications et sélectionnez ASP.NET 4.5 (ou ASP.NET 3.5 si vous devez prendre en charge des projets sur .NET Framework 2.0-3.5).
- Cliquez sur OK.
Exécutez-vous l'application API Web dans un répertoire virtuel ou une application?
Par exemple: j'ai eu le même problème lorsque j'ai déplacé mon projet vers mon IIS local sous le site Web par défaut> SampleWebAPI. Je pense que cela est dû au changement de routage URL comme suit:
Original: localhost:3092/api/values
Déplacé: localhost/SampleWebAPI/api/values
Si vous déplacez le projet d'API Web vers son propre site Web fonctionnant sur un port différent, il semble fonctionner.
Note complémentaire: j'avais encore compliqué le problème en ajoutant api comme alias d'une application de mon site Web qui entraînait le URL effectif comme suit:
localhost:81/api/api/values - remarqué après le déplacement du site Web sur son propre site Web
Par conséquent, parce que je souhaitais maintenir une séparation entre mon site Web et le site de projet Web api mvc, j’ai modifié les règles de routage dans global.asax pour l’API Web "DefaultAPI" de api/{controller}/{id} à {controller}/{id} et le code ASP.NET MVC Default de {controller}/{id} à info/{controller}/{id} .
C'est la seule réponse qui a fonctionné pour moi ...
J'avais un problème similaire ... Il semblait que quoi que je fusse, rien ne soit redirigé et mon fichier global était simplement ignoré. J'ai sérieusement envisagé de tout terminer avant d'avoir trouvé cette réponse. J'espère que ce lien aide quelqu'un d'autre.
Ajouter ce qui suit au fichier web.config a fonctionné pour moi:
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>
La balise system.webServer était déjà là bien sûr, mais j’y ai ajouté la balise modules puis les balises remove et add à la balise modules.
Quelques points à vérifier:
- Assurez-vous que .NET Framework 4 est installé.
- Assurez-vous que la version 4 du .NET Framework est sélectionnée pour votre site Web et votre répertoire virtuel (le cas échéant).
- Assurez-vous que MVC est installé ou que les DLL appropriées se trouvent dans votre répertoire bin.
- Peut avoir besoin d'autoriser les extensions de service Web ASP.NET 4.0
- Mettez l'application dans son propre pool d'applications.
- Assurez-vous que le répertoire dispose au minimum des autorisations d'exécution "Scripts uniquement".
J'avais un problème similaire. J'avais les bons paramètres dans mon fichier web.config mais le pool d'applications était exécuté dans mode classique plutôt que mode intégré
Ce problème peut également se produire en raison des problèmes suivants:
1. Dans le Web.Config
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<system.webServer>
2.Assurez-vous que les éléments suivants sont disponibles dans le dossier bin du serveur sur lequel l'API Web est déployée.
System.Net.Http
System.Net.Http.Formatting
System.Web.Http.WebHost
System.Web.Http
Par défaut, ces assemblys ne sont pas copiés dans le dossier bin si la publication s'effectue via Visual Studio, car les packages de l'API Web sont installés via Nuget sur la machine de développement. Si vous voulez que ces fichiers soient disponibles dans le cadre de la publication de Visual Studio, vous devez définir CopyLocal sur True pour ces assemblys.
Sadish Kumar.V
J'ai aussi rencontré ce problème. J'ai résolu le problème en accédant à Pools d'applications> Nom du pool d'applications et en modifiant le .NET Framework de la version v.2.0.50727 à la v4.0.30319.
Sur la base de cette SO réponse , il me suffisait de changer path="*." en path="*" pour le ExtensionlessUrlHandler-Integrated-4.0 ajouté dans configuration>system.WebServer>handlers dans mon web.config
Avant:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
Après:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
Il existe un correctif officiel de Microsoft: http://support.Microsoft.com/kb/980368
Je déconseille fortement d'utiliser <modules runAllManagedModulesForAllRequests = "true"> . Cela entraîne que toutes les demandes (même .jpg, .css, .pdf, etc.) seront traitées par tous les modules HTTP enregistrés . deux moments négatifs: a) charge supplémentaire sur les ressources matérielles; b) des erreurs potentielles, car les modules http traiteront un nouveau type de contenu.
Assurez-vous que le pool d'applications est en Mode intégré
Et ajoutez ce qui suit au fichier web.config:
<system.webServer>
.....
<modules runAllManagedModulesForAllRequests="true" />
.....
</system.webServer>
J'ai dû désactiver l'option de publication de fichier "Précompiler lors de la publication".
J'ai commencé à obtenir 404 réponses de l'API Web après avoir suivi un didacticiel Windows Azure qui me disait d'ajouter un fichier "WebRole.cs" à mon projet.
Après avoir supprimé "WebRole.cs" de mon projet, mes appels d'API Web ont recommencé à fonctionner.
Dans mon cas, le problème était simplement que j'essayais d'accéder au site à l'adresse
myserver.myintranet.com/mysite
Mais la liaison de site Web pour http dans IIS ne possédait pas le nom d'hôte spécifié dans la liaison. Cela avait fonctionné auparavant et je ne sais pas du tout comment ça a été emporté.
Une fois que j'ai mis myserver.myintranet.com dans le nom d'hôte, la 404 était partie.
Dans IIS Manager, accédez à Liaisons ... dans le volet Actions, puis éditez la liaison http pour spécifier le nom de l'hôte.
N'oubliez pas de déployer global.asax
Avait le même problème, une réponse 404 pour les contrôleurs de l'API Web lorsqu'il est servi à partir de IIS, mais tout a bien fonctionné à partir de VS2010. Aucune des solutions ci-dessus n'a fonctionné pour moi. Finalement, j'ai découvert que le problème était que nous avions ajouté la prise en charge de WSE 3.0 pour l'application et que la DLL Microsoft.Web.Services3 était manquante dans le répertoire/bin de l'application. Bizarre, mais après avoir copié la dll, la cartographie de route a commencé à fonctionner.
J'ai eu du mal avec ça aussi. Mon problème exact était que j'avais un service Web ASMX qui, lorsque j'inscrivais un paramètre dans une méthode Web et le testais, me donnait le 404. Cette méthode particulière avait bien fonctionné dans le passé et n'avait pas été modifiée, seulement republié. Puis je suis arrivé ici et j'ai essayé toutes les réponses affichées et rien n'y fait.
Ma solution ultime? Je sais que c'est drastique, mais je viens de créer une nouvelle solution Visual Studio et un projet Web. MVC sélectionné, puis "Ajouter"> "Nouvel élément", puis "Visual C #"> "Web" et "Service Web (ASMX)". J'ai copié la totalité de mon ancien code code-behind, puis j'ai pris note de l'espace de noms donné au nouveau fichier dans mon nouveau projet, puis collé tout mon ancien code dans le nouveau fichier code-behind du nouveau projet et mis l'espace de noms retour à ce qu'il avait été. J'ai ensuite créé mes dossiers dans mon projet avant d’utiliser Visual Studio pour "Ajouter"> "Nouveau dossier", puis je les ai copiés dans mes fichiers dans les dossiers de mon autre projet à l’aide de l’explorateur Windows. Cliquez ensuite avec le bouton droit de la souris Visual Studio, puis "Ajouter"> "Élément existant ..." et extraire les éléments de ces dossiers dans les dossiers Visual Studio de mon nouveau projet. J'ai de nouveau référencé tous mes assemblages .NET, en ouvrant les deux projets afin de pouvoir comparer ceux que j'avais référencés précédemment (j'en avais une tonne!). Je devais nommer mon nouveau projet légèrement différent - par exemple, je faisais quelque chose de comparable à "GeneralWebApp" au lieu de "MyWebApp", par exemple - alors je devais faire un "Remplacer tout" dans toute ma solution pour remplacer ce nom. obtenir le bon espace de noms pour tous mes fichiers. Ensuite, j'ai fait un "Rebuild All" sur le projet, puis je l'ai démarré avec le bouton "Play" que Visual Studio a donné lorsque je l'ai construit correctement. Cela a bien fonctionné. Alors je l'ai publié, et tout allait bien sur le serveur sur lequel je l'ai publié, quand je l'ai exécuté à partir de là. Je n'ai aucune explication sur ce qui s'est passé, mais c'est comme ça que je me suis débrouillé. Ce n'est pas un mauvais test que de voir si quelque chose que Visual Studio a fait a tout gâché.
Ce morceau de configuration dans le fichier web.config peut aider comme m'a aidé:
<security>
<requestFiltering>
<verbs applyToWebDAV="true">
<remove verb="PUT" />
<add verb="PUT" allowed="true" />
<remove verb="DELETE" />
<add verb="DELETE" allowed="true" />
<remove verb="PATCH" />
<add verb="PATCH" allowed="true" />
</verbs>
</requestFiltering>
</security>
Cela a été résolu pour moi, lorsque j'ai activé la case à cocher pour UrlRoutingModule-4.0:
Gestionnaire IIS> Modules> sélectionnez UrlRoutingModule-4.0> Edit Module> Cochez la case "Appeler uniquement pour les demandes adressées aux applications ASP.NET ou aux gestionnaires gérés".
Quel type de requête HTTP faites-vous?
Il s’agit d’une réponse légèrement à gauche, mais avez-vous essayé de supprimer la page d’erreur IIS par défaut pour 404 afin de vérifier ce que votre API renvoie réellement?
J'ai eu un problème dans lequel je voulais une méthode de contrôleur pour renvoyer un 404 lorsque je lui ai posté le mauvais identifiant. J'ai constaté que je recevais toujours la page IIS 404 "Fichier ou répertoire introuvable" plutôt que la réponse HTTP de mon API. La suppression de la page d'erreur 404 par défaut a résolu le problème.
Problème différent mais vous ne savez jamais que cela peut aider;)
Nous avons rencontré le même problème avec Web API et .Net Core Web API. A bien fonctionné dans VS 2017 lors du débogage, mais a renvoyé 404 lors de sa publication dans IIS 7.5. La solution pour moi était de changer la façon dont j'ai créé le site. Au lieu de publier à la racine d'un site Web (créé en cliquant avec le bouton droit de la souris sur Sites ... Ajouter un site Web), j'ai dû créer une application (créée en cliquant avec le bouton droit de la souris sur un site Web ... Ajouter une application) et la publier dans ce dossier. Notez que pour la version Core, je devais modifier le paramètre Version du pool d’applications .NET Framework en "Aucun code géré".
J'avais le même problème: sur un ordinateur nouvellement installé avec Visual Studio 2013, le projet d'API Web fonctionnait sous IISExpress, mais pas sous IIS local. J'ai essayé tout ce que je pouvais trouver, mais au final, le problème n'était pas nécessaire avec l'API Web, mais avec MVC: même s'il était installé, aucun projet MVC n'était en cours d'exécution.
Ce qui a fonctionné pour moi a été de désinstaller IIS (de AJOUTER/SUPPRIMER les fonctionnalités Windows), puis de le réinstaller, puis d’exécuter aspnet_regiis -i. Peut-être que cela aide quelqu'un d'autre.
J'ai passé beaucoup de temps à essayer de nombreuses choses pour finalement réaliser que j'ajoutais mon application Web non pas dans Sites/Sites Web par défaut, mais dans un autre site Web lié à un autre port. Évidemment, essayer de localhost sur le port 80 donnerait un 404.
J'ai récemment eu une erreur 404 non trouvée avec tous mes routes/contrôleurs Web Api 2. Alors je suis allé sur le serveur actuel et ai essayé de naviguer en utilisant localhost au lieu du nom d’hôte et j’ai eu "404.7 Introuvable - Le module de filtrage des requêtes est configuré pour refuser l’extension de fichier".
Pour moi, le problème était que le site racine était configuré pour utiliser un pool d'applications .NET 2.0 et que mon application au sein de ce site était .NET 4.5.
J'ai créé un nouveau site avec un pool d'applications .NET 4 et j'ai placé mon application à la racine de celui-ci - et cela a bien fonctionné.
je ne fais rien, il suffit d'ajouter cette balise dans web.config, son fonctionnement ce problème est l'un des points suivants
Utiliser Web Api dans le même projet à l'aide de formulaires MVC ou asp.net
Utilisez RouteConfig et WebApiConfig dans Global.asax En tant que GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);
Utilisez RouteConfig à deux fins, les formulaires asp.net utilisant les routages friendlyurl et mvc pour le routage MVC
nous utilisons simplement cette balise dans web.config, cela fonctionnera.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
.........................
</modules>
</system.webServer>