Страница Default.aspx не загружается на IIS 6 - PullRequest
1 голос
/ 16 февраля 2012

Запуск IIS 6 с основным веб-сайтом с использованием .net 4. У меня есть много дополнительных веб-сайтов, на которых в основном работает .net 4, и при их просмотре default.aspx автоматически загружается без проблем. Однако на одном из веб-сайтов работает .net 3.5, и файл default.aspx не загружается сам по себе при переходе по URL с открытым концом: http://127.0.0.1/TestApp, однако, если я перехожу непосредственно к файлу, он работает нормально: http://127.0.0.1/TestApp/Default.aspx.

Глядя на документы в веб-приложении .net 3.5, он показывает Default.aspx как «включенную страницу содержимого по умолчанию». Если я переключаю приложение на .net 4.0, автоматически загружается страница default.aspx. Я не могу сохранить этот параметр, потому что это скомпилированное веб-приложение, которое содержит ошибки на некоторых страницах и не имеет доступа для обновления кода.

Кто-нибудь видел эту проблему и знает, как ее решить? Любая помощь / идеи будут великолепны!

Спасибо!

EDIT

Страница ошибки Этот ресурс не может быть найден. Описание: HTTP 404. Ресурс, который вы ищете (или одна из его зависимостей), мог быть удален, изменилось его имя или временно недоступен. Пожалуйста, просмотрите следующий URL и убедитесь, что он написан правильно.

Запрошенный URL: /licensure/eurl.axd/ce90d150037c2545966c2948cd3e2e7e/


Информация о версии: Microsoft .NET Framework Версия: 2.0.50727.3053; ASP.NET версия: 2.0.50727.3053

1 Ответ

3 голосов
/ 16 февраля 2012

Возможно, вы захотите увидеть этот сайт: http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx

Похоже, что это связано с URL-адресами без расширений .NET 4.

На указанной выше странице ссылки:

Рекомендованные решения

Если вы отключите функцию расширения URL-адреса ASP.NET v4.0 на IIS6, задав DWORD в HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExtensionlessUrls = 0 и перезапустите IIS, после чего функция ASP.NET будет отключена, и вы не увидите «/eurl.axd/GUID» в своих URL-адресах, если вредоносный клиент не отправит такие запросы на ваш сервер.

Наше исправление

В нашем случае решение пришло от HeliconTech, который является поставщиком нашего IIS Rewrite Module

http://www.helicontech.com/forum/15029-ASPNET_40_MVC_and_ISAPI_Rewrite_3.html

Мы нашличто eurl.axd добавлялся, когда мы делали редирект.Файл eurl.axd был добавлен до перенаправления, поэтому isapi включает его, как если бы он был правильной частью URL.

Например, мы перенаправляем www на не-www.Чтобы игнорировать часть eurl.axd, мне пришлось изменить правило на:

RewriteCond% {HTTPS} (включено)?RewriteCond% {HTTP: Host} ^ www. (. +) $ [NC] RewriteCond% {REQUEST_URI} (. +)?RewriteRule ^ (. ) (eurl.axd /.) $ http (?% 1s): //% 2 / $ 1 [R = 301, L]

Если вы хотите перейтидругой способ и перенаправить не-www на www, это легко изменить:

RewriteCond% {HTTPS} (включено)?RewriteCond% {HTTP: Host} ^ (?! www.) (. +) $ [NC] RewriteCond% {REQUEST_URI} (. +)?RewriteRule ^ (. ) (eurl.axd /.) $ http (?% 1s): //www.%2/$1 [R = 301, L]

Надеюсь, это поможетПотребовалось некоторое время, чтобы его закрепить, но в наших общих средах решение работало как прелесть, не оказывая влияния на всех клиентов, отключив функцию без расширения или перенеся все на IIS7.

...