Приложение ASP.NET Web API выдает 404 при развертывании в IIS 7
У меня есть веб-API ASP.NET, который отлично работает при запуске на "IIS Express" с localhost:1783
Но когда я распаковываю "Использовать IIS Express", а затем нажимаю "Создать виртуальный каталог"...
... я просто получаю 404 ошибки:
Есть идеи, что не так? Спасибо!
12 ответов
Пока помеченный ответ заставляет его работать, все, что вам действительно нужно добавить в webconfig, это:
<handlers>
<!-- Your other remove tags-->
<remove name="UrlRoutingModule-4.0"/>
<!-- Your other add tags-->
<add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition=""/>
</handlers>
Обратите внимание, что ни у одного из них нет определенного порядка, хотя вы хотите, чтобы ваши удаления были до ваших добавлений.
Причина, по которой мы в итоге получаем 404, заключается в том, что модуль маршрутизации Url включает только корень сайта в IIS. Добавив модуль в конфигурацию этого приложения, мы получаем модуль для запуска по пути этого приложения (путь к вашему подкаталогу), и модуль маршрутизации запускается.
Для меня, в дополнение к runAllManagedModulesForAllRequests="true" Я также должен был отредактировать "path"атрибут ниже. Ранее мой атрибут пути был "*." Это означает, что он выполняется только на URL, содержащих символ точки. Тем не менее, URL моего приложения не содержат точки. Когда я переключил путь к "*" тогда это сработало. Вот что у меня сейчас:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule"/>
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Возможно, вам придется установить исправление KB980368.
В этой статье описывается обновление, которое позволяет определенным обработчикам служб IIS 7.0 или IIS 7.5 обрабатывать запросы, URL-адреса которых не заканчиваются точкой. В частности, эти обработчики отображаются на " ." пути запроса. В настоящее время обработчик, который сопоставлен с "." Путь запроса обрабатывает только запросы, URL-адреса которых заканчиваются точкой. Например, обработчик обрабатывает только запросы, URL-адреса которых похожи на следующий URL-адрес:
http://www.example.com/ExampleSite/ExampleFile.
После установки этого обновления обработчики, сопоставленные с "*." Путь запроса может обрабатывать запросы, URL-адреса которых заканчиваются точкой, и запросы, URL-адреса которых не заканчиваются точкой. Например, теперь обработчик может обрабатывать запросы, похожие на следующие URL:
http://www.example.com/ExampleSite/ExampleFile
http://www.example.com/ExampleSite/ExampleFile.
После применения этого исправления приложения ASP.NET 4 могут обрабатывать запросы на URL-адреса без расширений. Следовательно, будут запускаться управляемые модули HttpModules, которые выполняются до выполнения обработчика. В некоторых случаях HttpModules может возвращать ошибки для URL-адресов без расширения. Например, модуль HttpModule, который был написан для ожидания только запросов.aspx, теперь может возвращать ошибки при попытке доступа к свойству HttpContext.Session.
Эта проблема также может произойти из-за следующих
1. В Сети. Конфиг
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
2. Убедитесь, что в папке bin на сервере, где развернут веб-API, доступно следующее
• System.Net.Http
• System.Net.Http.Formatting
• System.Web.Http.WebHost
• System.Web.Http
Эти сборки не будут скопированы в папку bin по умолчанию, если публикация выполняется с помощью Visual Studio, поскольку пакеты Web API устанавливаются через Nuget на компьютере разработчика. Тем не менее, если вы хотите, чтобы эти файлы были доступны как часть публикации Visual Studio, вам нужно установить для CopyLocal значение True для этих сборок.
Некоторые люди говорят, что runAllManagedModulesForAllRequests="true" будет иметь проблемы с производительностью и маршрутизацией MVC. Они предлагают использовать следующее:
http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html
http://bartwullems.blogspot.com/2012/06/optimize-performance-of-your-web.html
Для меня эта проблема немного отличалась от других ответов, поскольку я получал только 404 с опциями, но у меня уже были опции, специально указанные в моих опциях встроенного обработчика URL-адресов без расширений. Очень запутанно.
- Как уже говорили другие, runAllManagedModulesForAllRequests="true" в узле модулей - это простой способ общего исправления большинства проблем Web API 404 - хотя я предпочитаю ответ @DavidAndroidDev, который гораздо менее навязчив. Но в моем случае было что-то дополнительное.
- К сожалению, у меня был этот набор в IIS в разделе Фильтрация запросов на сайте:
При добавлении следующего узла безопасности в web.config необходимо было это исключить - полный system.webserver включен для контекста:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<remove name="WebDAV" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<security>
<requestFiltering>
<verbs>
<remove verb="OPTIONS" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
Хотя это не идеальный ответ на этот вопрос, это первый результат для "IIS OPTIONS 404" в Google, поэтому я надеюсь, что это кому-то поможет; стоил мне час сегодня.
У меня была эта проблема с Blazor, и я обнаружил, что включение «baseUrl» NavManagers в мои вызовы контроллера решило проблему независимо от использования виртуального каталога или корневого веб-сайта.
Это сработало для меня!
string baseUrl = NavigationManager.BaseUri.ToString();
NavigationManager.NavigateTo(**baseUrl** + $"api/Download/DownloadFile?FileName=" + sFilename, true);
Я боролся с этой проблемой в течение нескольких дней, пробуя всевозможные подсказки. Моя машинка работала нормально, но новая машина, на которой я работал, давала мне ошибку 404.
В диспетчере IIS я сравнил сопоставления обработчиков на обеих машинах, чтобы понять, что многие обработчики отсутствуют. Оказывается, ASP.Net 5 не был установлен на машине.
Если вы используете Visual Studio 2012, загрузите и установите обновление 2, выпущенное Microsoft недавно (по состоянию на 4/2013).
Visual Studio 2012, обновление 2
В этом обновлении есть некоторые исправления, связанные с этой проблемой.
Для меня я получил ошибку 404 на своих сайтах, НЕ использующих IIS Express (используя локальный IIS) при запуске приложения, которое было IIS Express. Если бы я закрыл браузер, который использовался для запуска IIS Express, то 404 ушел бы. Для меня мой проект IIS Express вызывался в локальные службы IIS, поэтому я преобразовал проект IIS Express для использования Local IIS, и тогда все заработало. Похоже, по какой-то причине вы не можете одновременно запустить веб-сайт не IIS Express и Local IIS.
У меня была такая же проблема. После многих исследований и разработок я нашел проблему.
но если ваша конфигурация является хорошей, то это означает, что aspnet 64 bit и IIS хорошо, тогда единственная проблема, которую я увидел, - это путь " web api, берущий путь локальной директории", так что вам нужно его использовать. таким образом.. ~../../../ api / products /
Большое спасибо за сообщение о проблеме. Я склонился много Abt IIS и другие настройки в файле конфигурации.
Проведите целую неделю, после того, как все следующие настройки сработали! и наконец спасли.Удаление UrlScan из файловых файлов ISAPI в IIS решает проблему в нашем случае.