IIS6 проти IIS7 та IIS7.5: обробка URL-адрес зі знаком плюс (+) в базі (не запит рядків)


38

Для будь-якої URL-адреси зі знаком плюс (+) у базовій URL-адресі (не в рядку запитів) IIS7 та IIS7.5 (Windows Server 2008 та 2008 R2) не видають URL-адресу оброблювачу за замовчуванням у додатку ASP.NET . Я почав помічати проблему з увімкненим користувальницьким HTTP-обробником, *.htmlале у мене є та сама проблема *.aspx. IIS6 (Server 2003) не має проблем із цими ж URL-адресами.

Щоб повторити проблему, на сайті ASP.NET я створив набір файлів ASPX, які зробили просту Response.Write з різними іменами:

  1. test_something.aspx
  2. test_some + thing.aspx
  3. test_some thing.aspx

Третій файл був тестом, щоб перевірити, чи IIS7 [.5] розглядає плюс символи як пробіли (як це було б у рядку запитів); це, мабуть, не так. Якщо всі ці файли на місці, натискання http://somehost/test_some+thing.aspxабо http://somehost/test_some%2bthing.aspxбуде добре працювати в IIS6, але 404 в IIS7 / IIS7.5, перш ніж потрапити на будь-який обробник ASP.NET. Чи є в IIS7 / 7.5 якась конфігурація, яку мені не вистачає, щоб отримати «бачити» знак плюс у URL-адресі, не пропускаючи остаточне розширення, яке використовується для визначення обробника HTTP?


Цікаво, чи допоможе уникнути знака плюс. Можливо \+?
Призупинено до подальшого повідомлення.

Відповіді:


39

Після пошуку додаткових комбінацій IIS та плюс, виявляється, що IIS7 [.5] налаштований для відхилення URL-адрес зі знаком плюс за замовчуванням із-за страху страхувати використання цього символу; цей символ все ще дозволений у рядку запитів. Рішення полягає в зміні атрибута requestFiltering по замовчуванням на , <system><webServer><security><requestFiltering>щоб двічі закодовані символи з викликом командного рядка ( в кінцевому рахунку , модифікуючи ASP.NET web.config):

%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true

Це може бути дещо небезпечніше, ніж хтось вважає за краще їх веб-сайт, але, схоже, не існує способу бути більш конкретним, ніж дозволяє ковдра. Попередження стосувалися невідповідності, яка може виникнути між використанням плюсу в URL-адресі та типовим перекладом як пробіл. Схоже, єдиною іншою альтернативою є взагалі припинити використання плюс-символів у своїх URL-адресах.


2
Просто ПІІ: Вам не потрібно робити це в шаблоні кореневого рівня. Це можна зробити у будь-якому файлі Web.config або застосувати до підпапки з тегом <location />.
mdonatas

У IIS Manager: Sites => YourSite => Request Filtering => Edit Settings Feature ... => Check Allow double escape => OK
diynevala

9

Я щойно придумав, як скласти правило перезапису, щоб переконати IIS7 віднести плюси до пробілів у URL-адресах. У моєму випадку це потрібно було підтримувати застарілі закладки або гіперпосилання.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <security>
      <requestFiltering allowDoubleEscaping="True" />
    </security>
    <rewrite>
      <rules>
        <rule name="RewriteUserFriendlyURL1" stopProcessing="false">
          <match url="\+" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="{UrlDecode:{REQUEST_URI}}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Детальнішу інформацію та посилання див. У моєму блозі .


1
Я вирішив проблему, коли мені довелося підтримувати застарілі URL-адреси із знаками плюс у рядку запиту, використовуючи лише розділ безпеки вище, тобто встановивши дозвіл дозволу на "True".
Стефан

У мене є унікальний випадок - деякі застарілі URL-адреси мають два послідовних плюси, тобто "++". IIS, здається, має проти цього особливе правило. якісь ідеї?
бумгауер

@boomhauer вам може знадобитися написати обробник ... або використовувати інший веб-сервер для розміщення цих URL-адрес? Одного разу я змусив Apache mod_rewrite обробляти купу застарілих URL-адрес і перенаправляти їх на різні нові місця, і це здавалося трохи гнучкішим.
Натан
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.