Наши Windows / IIS 7.5 среда настроена с UrlScan и Фильтрация запросов IIS. У нас возникла проблема с длинным URL-адресом.
/MyWeb/TestFW/prweb/Servelt1/ZsvSk3vV8PtgJEa4_x3fiQ[[*/!MyWebApp/webwb/desktop_domainsuffix_1819019784.js!yui_13833664524!desktopwrapper_12997951049!automationscripts_1864420987!ui_jquery_1796787788!desktopwrapper_12997951049!automationscripts_1864420987!ui_jquery_1796787788!
Примечание: я изменил URL-адрес, но это структура, и она составляет около 880 байт, если я добавляю блокнот.
UlrScan.ini файл имеет все настройки по умолчанию для раздела Ограничения запросов:
MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048
Фильтрация запросов IIS также включен и имеет значения по умолчанию:
<security>
<requestFiltering>
<requestLimits
maxAllowedContentLength="30000000"
maxUrl="4096"
maxQueryString="2048"
/>
</requestFiltering>
</security>
Я провел тест, и URL-адрес, указанный в верхней части сообщения, завершился ошибкой 403. URL-адрес составляет 880 байт, поэтому, если фильтрация запросов имеет приоритет, она не должна завершиться неудачей, поэтому я предполагаю UrlScan выполняется без учета ограничений запросов IIS.
Я попросил своего администратора IIS предоставить журналы IIS пару раз, и во всех журналах, к которым был предоставлен общий доступ, я вижу только 403. Никаких ошибок 404 или 404.14, как упоминалось во всех других статьях службы поддержки Microsoft.
Так мои наблюдения верны? Какая конфигурация имеет приоритет при такой настройке? это UrlScan или фильтрация запросов IIS?
Я хотел бы услышать, есть ли возможность сделать фильтрацию запросов приоритетной над UrlScan настройки, поскольку фильтрация запросов настраивается до уровня приложения, где UrlScan.ini настраивается только до уровня сайта.
А также, согласно документации IIS, UrlScan функции включены в фильтрацию запросов IIS. Итак, почему существует огромная разница между значениями по умолчанию для максимального URL-адреса? 260 байт в urlscan.ini и 4096 байт в фильтрации запросов IIS.
UrlScan останавливает запрос до того, как он достигнет модуля фильтрации запросов IIS. Идеальным и рекомендуемым решением было бы списание UrlScan и использование только модуля фильтрации запросов IIS в IIS 7 и более поздних версиях. Этот модуль в IIS 7.5 имеет все функции модулей urlscan, поэтому нет никаких технических причин для отказа от вывода из эксплуатации. Но так как нашим администраторам это не понравилось, мы применили описанный ниже подход. Увеличьте maxUrl в модуле urlscan до 4096, что позволяет выполнять длинные запросы. Модуль фильтрации запросов можно настроить на уровне веб-сайта или сервера по умолчанию, который является глобальным, а также на уровне отдельных приложений. Таким образом, urlScan уровня веб-сайта по умолчанию был оставлен на 460 символов, что применяется ко всем приложениям, а в моем приложении maxUrl фильтрации запросов установлен на 4096. Таким образом, все остальные 50 приложений имеют ограничения, установленные по умолчанию несколько лет назад, а мое приложение имеет большую длину для обслуживания длинных запросов.
Спасибо.