Наш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настройки, поскольку фильтрация запросов настраивается до уровня приложения, тогда как as UrlScan.ini
настраивается только до уровня сайта.
А также, согласно документации IIS,UrlScanфункции включаются в фильтрацию запросов IIS. Так почему же существует огромная разница между значениями по умолчанию для максимального URL? 260 байт в urlscan.ini
фильтрации запросов IIS и 4096 байт в ней.
решение1
UrlScan останавливает запрос до того, как он достигнет модуля фильтрации запросов IIS. Идеальным и рекомендуемым решением было бы вывести UrlScan из эксплуатации и использовать только модуль фильтрации запросов IIS на IIS 7 и выше. Этот модуль в IIS 7.5 обладает всеми функциями модулей urlscan, поэтому нет технических причин не выводить его из эксплуатации. Но поскольку нашим администраторам это не понравилось, мы применили следующий подход. Увеличьте maxUrl в модуле urlscan до 4096, что позволяет обрабатывать длинные запросы. Модуль фильтрации запросов можно настроить на уровне веб-сайта по умолчанию или на уровне сервера, который является глобальным, а также на уровне отдельного приложения. Поэтому urlScan на уровне веб-сайта по умолчанию был оставлен на уровне 460 символов, что применяется ко всем приложениям, а в моем приложении maxUrl фильтрации запросов установлен на уровне 4096. Таким образом, все остальные 50 приложений имеют ограничения, установленные по умолчанию много лет назад, и мое приложение имеет большую длину для обслуживания длинных запросов.
Спасибо.