Как клиент HTTP должен правильно проанализировать *разделенный на блоки* Текст ответа HTTP?

Когда разделенное на блоки кодирование передачи HTTP используется, почему сервер должен выписать обоим размер блока в байтах и иметь последующий конец данных блока с CRLF?

Разве это не делает передающие двоичные данные "CRLF-грязными" и метод немного избыточный?

Что, если данным следовал за 0x0A 0x0D в нем где-нибудь (т.е. это на самом деле часть данных)? Клиент, как затем ожидают, будет придерживаться размера блока, явно обеспеченного во главе блока или дросселя на первом CRLF, с которым он встречается в данных?

Мое понимание до сих пор ожидаемого клиентского поведения состоит в том, чтобы просто взять размер блока, обеспеченный сервером, продолжиться к следующей строке, затем считать точно эту сумму байтов из следующих данных (CRLF или никакой CRLF там), затем пропустить CRLF после данных и повторить процедуру до больше никаких блоков. Это совместимое поведение? Если так, какой смысл CRLF после каждого datachunk затем? Удобочитаемость?

Я сделал некоторый веб-поиск на этом и также сделал некоторое чтение спецификации HTTP 1.1, но категорический ответ, кажется, ускользает от меня.