Пакетный запрос веб-API, размещенный в IIS, возвращает 404 для внутренних URL-адресов

Я разрабатывал RESTful API с использованием Web Api 2, и в его рамках я реализовал пакетные запросы с использованием объектов JSON, как описано в одной из их статей вики (https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching).

Этот процесс прошел достаточно гладко при тестировании с использованием IIS Express, но когда я развернул приложение в IIS 8 под приложением IIS, пакетные запросы перестали работать должным образом. Каждый дополнительный запрос возвращает 404, не найдено, даже если URL-адрес указывает на правильное местоположение. Однако это происходит только тогда, когда программа развернута как приложение на веб-сайте IIS. Если просто закинуть программу в корень сайта IIS, пакетная обработка ведет себя корректно.

У меня есть несколько изображений ответов об ошибках/успехах в Fiddler, но SO не позволяет мне их публиковать. Например, пакетный запрос POST, отправленный на веб-сайт IIS, размещенный по адресу «http://domain.com/api/v1.0/» с внутренним URL-адресом, установленным на «realtimedata/queues?queueIds=1», работает нормально, но когда приложение доступно по адресу «http://domain.com/test/api/v1.0/», тот же запрос с тем же внутренним URL возвращает 404, хотя «http://domain.com/test/api /v1.0/realtimedata/queues?queueIds=1" — вполне допустимый адрес, который можно назвать прекрасным без использования пакетного запроса. (Пробел между «http» и «домен» в примерах URL-адресов предназначен только для того, чтобы обойти ограничение ссылок SO, поэтому представьте, что их там нет). Кто-нибудь знает, что происходит?


asp.net-web-api iis asp.net-web-api2
person Nathan G    schedule 31.03.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

После дополнительного тестирования я обнаружил, что это проблема, связанная с хостингом через OWIN в IIS. Мне пришлось зарегистрировать свои маршруты для объекта GlobalConfiguration.Configuration вместо нового объекта конфигурации, и тогда ошибки 404 были разрешены. Я не уверен, почему это произошло, но это сработало.

person Nathan G    schedule 12.05.2015
comment
Хм, у меня была такая же проблема без OWIN, и я использовал GlobalConfiguration.Configuration для этого. В любом случае решение, которое я дал работы для меня. - person Konstantin Ryazantsev; 12.05.2015

arrow_upward
0
arrow_downward

Добавьте/измените раздел system.webServer в файле web.config в соответствии с этим образцом:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
    <handlers>
        <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
        <remove name="OPTIONSVerbHandler" />
        <remove name="TRACEVerbHandler" />
        <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
</system.webServer>

Обратите внимание, что path="/*" заменено на path="*." в теге add.

person Konstantin Ryazantsev    schedule 07.05.2015