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

SQLite разработан как встроенная база данных, то есть для использования вместе с «реальным» языком программирования. Чтобы иметь возможность использовать такие динамические конструкции, вы должны выйти за пределы самого SQLite:

cursor.execute("SELECT name FROM sqlite_master")
rows = cursor.fetchall()
for row in rows:
    sql = "SELECT ... FROM {} WHERE ...".format(row[0])
    cursor.execute(sql)
30
задан Community 23 May 2017 в 12:25
поделиться

1 ответ

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

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

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

  2. Далее запускается ваш URL rewriter, специфический для сайта ISAPI-фильтр, и видит искаженный URL. Поскольку ваши правила не ожидают URL с такой странной последовательностью, ваш фильтр перезаписи не обрабатывает его должным образом, и пользователь, вероятно, получает сообщение 404.

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

Что Microsoft намеревалась сделать:

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

  2. aspnet_isapi.dll ISAPI application принимает запрос, распутывает URL, удаляя /eurl.axd/some-long-number, и передает его коду ASP.NET, предназначенному для обработки URL без расширений. Этот код обрабатывает запрос и не понимает, что махинации с /eurl.axd/some-long-number вообще имели место.

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

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

  • Используйте ключ реестра, чтобы просто отключить его. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 > DWORD EnableExtensionlessUrls to 0 , затем перезапустите IIS.

  • Выполните перезапись URL в рамках конвейера ASP.NET. (Очевидно, что в этом случае вы можете переписывать только управляемые запросы).

  • Установите ваш ISAPI-фильтр URL rewriter на глобальном уровне с приоритетом выше, чем aspnet_filter.dll. Звучит как боль.

  • Настройте веб-сайт на использование ASPNET v2, а не ASPNET v4.

  • Вставьте правило в ваш рерайтер, чтобы полностью игнорировать URL с eurl.axd в них. Это может быть просто
    RewriteRule eurl\.axd -

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

Удачи!

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

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

43
ответ дан 27 November 2019 в 23:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: