Как стать автором
Обновить

Комментарии 3

Интересно, а механизм серверного gzip-сжатия случайно не содержит уязвимостей для zip-бомб? Сервер отправляет клиенту пожатую gzip фейковую страницу, браузер клиента её получает и пытается... пытается... пытается... и падает с OOM, вероятно :)

Лет 15 назад столкнулся с похожей проблемой в MS SQL. на проде у нас создавались ежедневные бекапы - с включённой компрессией. И вот я взял последний, притащил на сендбокс и начал разворачивать. Через пару часов он положил весь сервер. Оказалось, что он во-первых, он создал базу на всё свободное пространство (ну что-то типа 1.5ТБ). при том, что изначальная база была в 20ГБ, не больше. Во-вторых, SQL сервер при восстановлении нагрузил сервер на все 100%.
Затем я сделал бекап без компрессии и он восстановился нормально. Проблема продлилась пару дней, а потом пропала. То есть те самые бекапы смерти остались, но новые бекапы даже со сжатием работали нормально. Что это было - мы так и не поняли.

мы на что-то схожее налетали, но там причина кажется была в том, что сервер при разворачивании пытался создать один из файлов максимально указанного размера, хотя реально использовано из него была лишь малая часть. традиционный shrink и указание корректного значения тогда спасли ситуацию

Зарегистрируйтесь на Хабре, чтобы оставить комментарий