Ошибки ASP.NET MVC eurl.axd

Используя следующие шаги:

(Я проверил этот похожий пост, который не решает мою проблему.)

В Windows Server 2003/IIS6 я создаю новый сайт под названием "testapp"
В VS2010 я создаю новое приложение ASP.NET MVC 2.

Я добавляю представление под названием "Информация" со следующим кодом:

<h2>System</h2>

<h3>Request</h3>

<%
    foreach (string key in Request.Headers)
    {
        Response.Write(string.Format("<p>{0}={1}</p>"
                , key
                , Request.Headers[key])
                );
    }


%>

В дополнение к стандартным заголовкам я вижу это:

   X-REWRITE-URL=/home/info/eurl.axd/e3299f29f8043d4f8a27e0f1d0c40971

Я использую Helicon ISAPI Rewrite 3, который генерирует заголовок "X-REWRITE-URL".

Моя проблема заключается в следующем: откуда идет /eurl.axd?....? Я видел эту статью, но поскольку это пустое приложение в новой папке с новым пулом приложений, там нет версии 2.0. * приложений, работающих в этой веб-папке. Нет виртуальных папок, указывающих на другой каталог и т.д. Сайт настроен для ASP.NET 4.0, который зарегистрирован правильно.

Проблема в том, что eurl.axd вворачивается с параметрами в моих маршрутах MVC.

Параметры в статье "Модифицированные изменения для ASP.NET 4.0" на самом деле не работают для меня, потому что в этом приложении нет никаких компонентов 2.0, и мне нужно использовать URL-адреса без расширения.

Обновление Я только что заметил, что System.Web.MVC в GAC - это версия 2.0.0.0. Если обновление было обновлено до версии 4.0 с установкой VS2010 и рамки 4.0?

Я не понимаю, почему я вижу эту ошибку с приложением ASP.NET MVC по умолчанию. Помощь!!

Обновление 2/2011 - Решено

Наконец, попробовав отключить URL-адреса без продолжения без изменений, проблема исчезла. Я нахожу контр-интуитивно понятным, что отключение сторонних URL-адресов упрощает работу с URL-адресами без расширения (с сопоставлением подстановочных знаков в IIS6), но я возьму то, что могу получить.

Обновление 12/2014

Я забыл упомянуть, что каждое другое обновление Windows вызвало изменение реестра. Это выглядело как странные проблемы, когда запрос на http://site.dom/bob потерпел неудачу, а http://site.dom/bob/ - успешно. Повеселись! (Обратите внимание на конечную косую черту.)

Ответ 1

Это часть подхода Microsoft, позволяющего без перенаправления URL-адресов ASP.NET v4 по умолчанию в IIS 6. Он описан здесь в ASPNET V4 Ломающиеся изменения. (Искать в этом документе для eurl.axd). Это происходит только с ASPNET v4.

Что происходит:

aspnet_filter.dll, глобальный фильтр ISAPI, который реализует ASPNET (щелкните правой кнопкой мыши папку "Веб-узлы" > "Свойства", чтобы увидеть его) проверяет каждый входящий URL-адрес. Для тех URL-адресов, которые не имеют расширения, ASPNET управляет URL-адресом для вставки /eurl.axd/some-long-number в него. На самом деле длинное число - это указатель без дефиса.
Ваш URL-ретранслятор, фильтр ISAPI для конкретного сайта, запускается дальше и видит искаженный URL-адрес. Поскольку ваши правила не ожидают URL-адресов с этой нечетной последовательностью, введенной в них, ваш фильтр перезаписи не обрабатывает его должным образом, и пользователь, вероятно, закончит с 404.

Это произойдет с любым фильтром перезаписи - Helicon ISAPI_Rewrite, IIRF и т.д. - при установке с IIS6 и ASPNET v4. Это может также произойти с другими фильтрами ISAPI - теми, которые явно не перезаписываются.

Что планировалось Microsoft:

aspnet_filter.dll Фильтр ISAPI добавляет /eurl.axd/some-long-number к URL без продолжения. (Если URL-адрес имеет расширение в нем, он оставляет его в покое, что позволяет сэкономить производительность при ударе управляемого кода.) Это просто для того, чтобы получить ".axd", поэтому IIS6 в своей конфигурации по умолчанию будет отображаться в aspnet_isapi.dll Расширение ISAPI (приложение).
Приложение aspnet_isapi.dll ISAPI подбирает запрос, разрывает URL-адрес, удаляя /eurl.axd/some-long-number и передает его в код ASP.NET, предназначенный для обработки URL-адресов без расширения. Этот код обрабатывает запрос и не понимает, что произошли события /eurl.axd/some-long-number shenanigans.

Microsoft не рассмотрела, что произойдет для проверки URL-адресов фильтров ISAPI, которые находятся между шагами 1 и 2. В примечаниях к выпуску ASP.NET 4 есть заметка о приложениях .NET 2.0, вызывающих эту ошибку; что только один способ это может произойти.

У вас есть несколько вариантов:

Используйте ключ реестра, чтобы отключить его. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 > DWORD EnableExtensionlessUrls до 0, затем перезапустите IIS.
Переписывать URL в конвейере ASP.NET. (Очевидно, вы можете переписать управляемые запросы только в этом случае.)
Установите URL-адрес переписывающего URL-адреса фильтра ISAPI на глобальном уровне с приоритетом выше aspnet_filter.dll. Мне кажется болью.
Настройте веб-сайт для использования ASPNET v2, а не ASPNET v4.
Вставьте правило в свой перезаписывающее устройство, чтобы полностью игнорировать URL-адреса с помощью eurl.axd. Это может быть так же просто, как и RewriteRule eurl\.axd -

Я использую раздел реестра, и он отлично работает для меня.

Удачи!

UPDATE 2011-08-10: Похоже, что Windows Updates, обслуживающий .NET Framework reset раздел реестра, и его необходимо повторно использовать.

Редактировать 2012-02-17 У нас была эта проблема, и наша команда провела несколько часов работы над проблемой, прежде чем кто-то нашел, что это похоронено в комментариях, завершило решение для нас. "Обратите внимание, что для Wow64 (т.е. 32-разрядного рабочего процесса, работающего на 64-разрядной ОС) этот раздел реестра должен быть установлен в HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExte nsionlessUrls."

Ответ 2

Я использую следующее регулярное выражение как правило first с помощью Ionics Isapi Rewriter для веб-сайтов, работающих на ASP.NET 4 на IIS 6, для устранения проблем, вызванных нарушение изменений, представленное в ASP.NET 4:

RewriteRule ^(.*)/eurl.axd/[a-f0-9]{32}(.*)$ $1$2

Это позволяет мне снова использовать неограниченные URL-адреса.

Обратите внимание, что вторая группа фиксирует запрос, если он присутствует, и заменяет его на перезаписанный URL.

И да, это функция, а не ошибка.

Ответ 3

Я столкнулся с подобной проблемой и нашел решение через нашего провайдера модуля ISAPI Rewrite. Я задокументировал вывод и решение: http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx