cwninja , к сожалению, дал вам ответ, который будет работать только для случайных атак.Интеллектуальный злоумышленник без проблем победит эту проверку.Есть две основные причины, по которым его метод не должен использоваться.Во-первых, ничто не гарантирует, что информация в ответе HEAD будет соответствовать соответствующему ответу GET.Правильно работающий сервер, безусловно, сделает это, но злоумышленник не должен следовать спецификации.Злоумышленник может просто отправить ответ HEAD, в котором говорится, что он имеет Content-Length, который меньше вашего порога, но затем передаст вам огромный файл в ответе GET.Но это даже не покрывает потенциальную возможность отправки сервером ответа с набором заголовков Transfer-Encoding: chunked.Частичный ответ вполне может никогда не закончиться.Несколько человек, указывающих вашему серверу на бесконечные ответы, могут проводить тривиальную атаку с исчерпанием ресурсов, даже если ваш HTTP-клиент применяет тайм-аут.
Чтобы сделать это правильно, вам необходимо использовать библиотеку HTTP, котораявам подсчитать байты по мере их получения и прервать, если он пересекает порог.Я, вероятно, рекомендую Curb для этого, а не Net :: HTTP.(Можно ли вообще сделать это с помощью Net :: HTTP?) Если вы используете обратные вызовы on_body и / или on_progress, вы можете подсчитать входящие байты и прервать промежуточный ответ, если получите слишком большой файл.Очевидно, как уже указывалось cwninja , если вы получаете заголовок Content-Length, превышающий пороговое значение, вы также хотите прервать его.Ограничение также заметно быстрее, чем Net :: HTTP .