(Chunked) тело двоичного сообщения HTTP и CRLFs
Я не могу получить окончательный ответ на следующий вопрос (в основном в Гугле и чтение спецификаций HTTP / 1.1):
когда используется кодировка передачи "chunked", почему сервер должен выписывать размер куска в байтах и иметь последующий конец данных куска с CRLF. Разве это не делает отправку двоичных данных "crlf-unclean" и метод немного избыточным? Что делать, если данные имеют 0x0A, а затем 0x0D в нем где-то (т. е. они на самом деле являются частью данных)? Это клиент должен придерживаться размера куска, явно предоставленного во главе куска или дросселя на первом CRLF, который он встречает в данных? Мое понимание до сих пор состоит в том, чтобы просто взять размер куска, предоставленный сервером, перейти к следующей строке, а затем прочитать именно это количество байтов из следующих данных(CRLF или нет CRLF внутри), затем пропустить этот CRLF, который следует за данными, и повторите процедуру до тех пор, пока не будет больше кусков... Я прав? Какова точка CRLF после каждого datachunk тогда? Читаемость?
2 ответов
разделенный потребитель не сканирует тело сообщения для пары CRLF. Сначала он считывает указанное количество байтов,а то считывает еще два байта, чтобы подтвердить, что они CR и LF. Если это не так, тело сообщения плохо сформировано, и либо размер был указан неправильно, либо данные были повреждены иным образом.
отставая CRLF обеспечение пояс-и-подтяжек (в RFC 2616 раздел 3.6.1, Поблочное Кодирование), но это также служит для поддержания согласованного правила, что поля начинаются в начале строки.
CRLF после каждого куска, вероятно, просто для лучшей читаемости, поскольку это не обязательно из-за размера куска в начале каждого куска. Но CRLF после "заголовка чанка" необходим, поскольку после размера чанка может быть дополнительная информация (см. Кодировка Передачи Фрагментов):
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF