Модуль UrlRewriting.Net + IIS7 равно Page.User == ноль?

Question

Я уже пару лет без проблем использую модуль UrlRewriting.Net в Windows XP и Windows 2003. Недавно я обновил свой домашний ПК до Windows 7 и начал разработку нового веб-сайта.

План состоял в том, чтобы использовать расширения .html и переписать их для своих аналогов .aspx с помощью модуля UrlRewriting.Net. Все работает безупречно в VWD 2008 , но когда я пытаюсь запустить его через IIS7, это другая история.

Когда я пытаюсь получить доступ к странице через .html, я больше не могу получить доступ к Page.User; он продолжает возвращать ноль. Если я попаду на страницу с расширением .aspx, Page.User будет заполнен правильно. Я должен также упомянуть, что у меня есть контроллер LoginView на моей мастер-странице, и он страдает от тех же симптомов: при доступе через расширение .html он показывает AnonyousTemplate; При использовании расширения .aspx он правильно показывает LoggedInTemplate. Я предполагаю, что оба связаны.

[Примечание: я также пробовал URL-адреса без расширений, и они показывают ту же проблему]

Единственный способ заставить его работать - это переключить пул приложений на классический, что затем требует от меня добавления обработчика ddl ASP.Net для расширения .html [в противном случае он обрабатывается StaticFileHandler и появляется как ошибка 404]. Однако я хотел бы, чтобы мое веб-приложение работало правильно для людей, не прибегая к помощи IIS.

Итак, у меня осталось несколько вопросов:

• У кого-нибудь есть идеи относительно того, почему Page.User всегда равняется нулю для переписанных страниц .html => .aspx?
• Почему он работает в VWD 2008, но не в IIS7?
• Что изменилось с IIS6 => IIS7, что могло вызвать это?
• Есть еще какие-нибудь мысли по поводу обходных путей?

[Примечание: я только что попробовал перезаписать .aspx => .aspx, но проблема не возникла. Не совсем то, что я хочу, но подумал, что должен это упомянуть.]

Answer 1

Только что произошел прорыв с модулем UrlRewriting.Net. Это заставляет его работать в интегрированном режиме в IIS7:

<modules runAllManagedModulesForAllRequests="true">

После выяснения этого я выполнил поиск по "runAllManagedModulesForAllRequests", и первым, что появилось, был блог Скотта Гатри , который фактически говорит об использовании его для этой цели.

Answer 2

Другой подход, который, похоже, работает, - это удалить модуль Session и прочитать его, оставив флажок «Вызывать только запросы к приложениям ASP.NET или управляемым обработчикам» не установленным. В файле web.config это выглядит так:

<system.webServer>
  <modules>
    <remove name="Session" />
    <add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </modules>
</system.webServer>

Кажется, проблема в том, что модуль Session не выполняется, скажем, для файлов * .htm, когда используется HttpContext.RewritePath, но удаление и чтение модуля таким способом приводит к выполнению обработчика сеанса для запроса .

Это решение было предложено в теме ниже. К сожалению, Microsoft решила не полностью объяснять причины такого поведения:

http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7

Answer 3

Microsoft включила исправление для этой проблемы (по крайней мере для URL без расширений) в Пакет обновления 1 для Win7 и Windows Server 2008 R2: http://www.microsoft.com/download/en/details.aspx?id=5842

Также доступно как исправление: http://support.microsoft.com/kb/980368

После применения этого исправления приложения ASP.NET 4 могут обрабатывать запросы на URL-адреса без расширений. Поэтому будут запускаться управляемые модули HttpModules, которые выполняются до выполнения обработчика. В некоторых случаях HttpModules может возвращать ошибки для URL-адресов без расширения. Например, модуль HttpModule, который был написан так, чтобы ожидать только запросы ASPX, теперь может возвращать ошибки при попытке доступа к свойству HttpContext.Session.

После установки пакета обновления 1 (SP1) или исправления не требуется вносить изменения в web.config, чтобы сеанс и аутентификация форм работали для URL без расширений, переписанных на страницы / обработчики asp.net / и т. Д.

Я не знаю, исправляет ли это что-нибудь для перезаписи в статические расширения файлов, такие как .htm. Я думаю, вероятно, нет. Я бы постарался избежать установки runAllManagedModulesForAllRequests = "true" в производственных средах, потому что это добавляет ненужные накладные расходы на запросы статических файлов.