Протокол HTTP / 1.1, как указано в RFC7230, не имеет состояния, но метод запроса HEAD должен генерировать некоторое состояние на стороне клиента и в прокси, поскольку нет другого способа определить длину тела сообщения ответа на запрос HEAD.
Существует только несколько способов определить фактическую длину передачи HTTP-ответа.Они описаны в 3.3.3 RFC7230.
Предположим, что конвейер HTTP-запроса находится в действии, и клиент генерирует некоторую допустимую последовательность HEAD и GET для некоторых существующих ресурсов на исходном сервере, и существует прозрачный HTTP-прокси на пути от клиента к исходному серверу.
Протокол HTTP определен как не имеющий состояния, поэтому никакое состояние не должно создаваться ни в какой части сообщения или каким-либо действием, предпринимаемым самим протоколом (а не транспортным протоколом, который должен генерировать какое-либо состояние, такое как TCP, для изменения порядка сообщений и т. Д.)..).
Как прокси должен идентифицировать ответ сервера конца источника (например, длина тела сообщения) на запрос HEAD клиента, если тот факт, что этот запрос был выполнен, не должен запоминаться прокси (не должен генерироватьгосударство)?
Если прокси-сервер слепо интерпретирует поля Content-Length или Transfer-Encoding, отправленные исходным сервером в ответ на метод HEAD, он будет блокировать ожидание тела сообщения в течение неопределенного времени, пока исходный сервер никогда не отправит тело сообщения.,
Поэтому клиент должен сгенерировать некоторое состояние, чтобы помнить, что был отправлен не GET, а запрос HEAD (из-за той же проблемы - нет способа определить длину тела сообщения).
Таким образом, метод HEAD по своей сути является протоколом с состоянием в HTTP-протоколе без сохранения состояния, и это противоречие.
И что делает ситуацию еще хуже, так это то, что метод HEAD должен быть реализован любым сервером, как указано в 4.1 RFC7231, и на него нельзя ответить 501 или 405.
Это противоречие делает возможнымреализовать простой вектор атаки на HTTP-прокси: заполнить прокси запросами HEAD, чтобы сгенерировать достаточно состояния, чтобы сделать ошибку нехватки памяти.
Небольшое исследование, которое я провел, показывает, что современные прокси заменяют запрос HEAD на запрос GET, но это будет генерировать даже больше состояния и трафика, чем простое запоминание пути ресурса и типа запроса (в некоторых хэш-картах дляпример).
Поэтому я могу сделать вывод, что наличие запроса HEAD противоречит отсутствию состояния протокола HTTP / 1.1.