Пятничные раздумья. Сегодня настраивал nginx и заметил там атрибут (по умолчанию на 1000), указывающий количество байт, меньше которого контент не gzip-ируется, потестил, действительно работает. Стало интересно, а есть ли подобное в IIS, плюс вспомнилась недавняя тема про gzip. Оказалось есть - minFileSizeForComp, через GUI IIS атрибут добавляется в applicationHost.config прямиком к <httpCompression>. Проблема оказалась проста - он нихрена не работает (тестил и на статике и на динамике). Вроде тянется с 7-ых версий IIS, у меня 8-ая, а результата ноль. Полез гуглить, первая ссылка , вторая , третья , чуваки с такой же проблемой и решения нет (в msdn ещё байты с килобайтами перепутали, но это мелочи). Собственно вопрос - всё действительно так грустно или можно починить?

И второе, сижу на IIS8, а обработчик 400-ой ошибки ( привет sql.ru ) до сих пор не напишешь. Отсюда вопрос - кто-нить писал фильтры над IIS (нужно вырезать контент, отдаваемый http.sys при ошибке 400 и подменять своим)? Теорию пока не курил.

Это не реальные задачи, а так, занятие на выходные.

hVosttst_st,

gzip можно делать фильтром по своему собственному алгоритму, хоть в зависимости от лунных затмений.

по поводу кодов ошибок




никаких поводов для грусти даже в намёках нет.

gzip - свой код написать то можно, но смысл данного атрибута и GUI к нему тогда в чём, просто чтобы было?

400 - давай на практике проверим. Есть IIS? :)

hVosttst_st400 - давай на практике проверим. Есть IIS? :)

а что такое? гугл опять по стране выборочно отключили?



Ага, и stackoverflow тоже. Точнее там писали, что 400-ую перехватить невозможно, но неповерил.

Ну есть <httpErrors existingResponse="PassThrough" />, а дальше чё с ним? 400 как вылетало, так и вылетает.

Да не, знак процента - это единичный случай получения 400 и я его привёл лишь потому, что он хорошо иллюстрирует проблему, просто перейдя по ссылке. А получить 400 другим способом не составляет труда, просто послав на сервер некорректный запрос, к примеру через тот же telnet. Поэтому ищу решение для всех 400-ых, а не именно для процента. И собственно в первоначальном вопросе спрашивал про вырезание контента, выдаваемого http.sys (создание фильтра), так как не нашёл как поймать 400 обычными средствами.

hVostt решение, которое я выше привёл отлично работает с внутренними бэд-реквестами.

400 хорошо ловится при отладке в VS на встроенном веб-сервере. Но на реальном IIS что имеем, то имеем, как написали выше по ссылке - "This is blocked right in the IIS kernel level".

Решение - при 400 выдавать вместо стандартного ответа IIS-а свою собственную страницу ошибок, как мог бы это я сделать на других веб-серверах.

hVosttбред. у меня всё работает на реальном IIS. обработка же корявых URL меня вообще не интересует. если пользователь ввёл в адресной строке какую-то лажу (типа % или ещё что-то из запрещённых символов) мне абсолютно параллельно, что он в итоге увидит. я не знаю почему вас это волнует. чтобы попасть на системную ошибку 400, надо специально постараться .

Не, ну и у меня тоже IIS работает, даже сайт показывает

Вобщем ладно, вернулись с чего начинали.