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)
Это часть подхода Microsoft к тому, чтобы позволить URL без расширений обрабатываться ASP.NET v4 по умолчанию в IIS 6. Он описан здесь в документе ASPNET V4 Breaking Changes. (Ищите в этом документе eurl.axd). Это происходит только с ASPNET v4.
Что происходит:
aspnet_filter.dll
, глобальный ISAPI-фильтр, реализующий ASPNET (щелкните правой кнопкой мыши папку Web Sites > Properties, чтобы увидеть его), проверяет каждый входящий url. Для тех урлов, которые не имеют расширения, ASPNET затем изменяет URL, вставляя в него /eurl.axd/some-long-number
. На самом деле длинный номер - это guid без тире.
Далее запускается ваш URL rewriter, специфический для сайта ISAPI-фильтр, и видит искаженный URL. Поскольку ваши правила не ожидают URL с такой странной последовательностью, ваш фильтр перезаписи не обрабатывает его должным образом, и пользователь, вероятно, получает сообщение 404.
Это произойдет с любым фильтром перезаписи - Helicon ISAPI_Rewrite, IIRF и др. - когда установлен IIS6 и ASPNET v4. Это может произойти и с другими ISAPI-фильтрами - теми, которые не являются явными перезаписывателями.
Что Microsoft намеревалась сделать:
aspnet_filter.dll
ISAPI filter добавляет /eurl.axd/some-long-number к URL без расширения. (Если в URL есть расширение, он оставляет его в покое, экономя производительность от попадания в управляемый код). Это просто для того, чтобы получить ".axd" там, так что IIS6, в своей конфигурации по умолчанию, будет сопоставлен с aspnet_isapi.dll
ISAPI расширением (приложение).
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."