IIS7: перезапись URL с периодом - PullRequest
Новая
       60

IIS7: перезапись URL с периодом

6 голосов
/ 21 февраля 2011

Я использую оптимизированные для SEO URL-адреса и могу обработать большинство из них с помощью ASP.NET, сопоставив aspnet_isapi.dll со всеми URL-адресами. (Я установил отображение обработчика в IIS, которое использует dll для всех путей. (Path = *))

Однако, похоже, что это не работает, когда последний символ «подпапки» - точка. Например, у меня есть URL /brakes/A.B.S./, и это не вызовет сопоставление. Таким образом, я получаю 404 для таких URL. Кто-нибудь знает, как я должен настроить отображение, чтобы вызвать это? (Я пробовал *. И это тоже не работает.)

Ответы [ 4 ]

7 голосов
/ 27 февраля 2011

Попробуйте изменить этот параметр в файле web.config: 

<httpRuntime relaxedUrlToFileSystemMapping="true" />

http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx

0 голосов
/ 03 февраля 2016

В моем случае я не мог сделать это с помощью перезаписи URL, хотя была еще одна причина - сканирование URL.

Я открыл windows \ system32 \ inetsrv \ urlscan \ urlscan.ini в текстовом редакторе и включил AllowDotInPath , изменив его значение на 1

0 голосов
/ 27 марта 2014

Я использую маршрутизацию атрибутов Web API

Выбранный ответ не работает для меня, это только частичное решение.

, чтобы убедиться, что веб-API получит первый взлом, не только вам понадобится 

<configuration>
  <system.web>
    <httpRuntime relaxedUrlToFileSystemMapping="true"/>
  </system.web>
</configuration>

вам также нужно иметь 

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true"></modules>
</system.webServer>

Я нашел ответ здесь в этом блоге:

РАЗРЕШИТЬ ТОЧКУ В ПРИЛОЖЕНИИ ASP.NET MVC (ОСОБЕННО IIS 7 +)

0 голосов
/ 06 марта 2011

Как уже указывал Мэтью, это разрешается в .NET 4.0, но не в .NET 2.0. Проблема заключается в базовой системе: Microsoft запрещает имена заканчиваться точкой (или пробелом), потому что Windows Explorer не может их обработать (однако базовая система NTFS может обрабатывать их).

В чем причина

Внутренне, и это верно для .NET 2.0 и .NET 4.0, веб-запрос в какой-то момент передается методу IsSuspiciousPhysicalPath. Помимо прочего, этот метод вызывает стандартный API для создания «официального» пути на основе указанного пути. Это не создает этот путь. Затем он сравнивает этот правильный путь с данным путем. Если они отличаются (т. Е. Если данный путь не существует в исправленном пути), это считается подозрительным.

Вы можете попробовать это сами: используйте File.CreateFile, чтобы создать файл "test.txt ....". Это будет успешно, но в результате файл "test.txt". В приведенном выше сценарии указанный файл "text.txt ...." не соответствует созданному файлу, поэтому он является подозрительным и даже не достигает обработчика веб-запросов.

Даже обработчик 404 в базовых настройках IIS здесь не будет работать!

надуманный обходной путь

Обходной путь, который я использовал годами во многих установках (по причинам, не связанным с этой проблемой): установите Apache перед IIS и настройте его для прокси. Его относительно легко настроить (он потерян примеров в Интернете), и он может служить буфером для обработки такого рода «незаконных запросов», переписывая их в нечто, что IIS может обрабатывать.

Но, вероятно, проще перейти с .NET 2.0 на .NET 4.0

...