Почему некоторые серверы не используют CRLF после последней длины пакета?

Question

Я работаю с инструментом запроса HTTP (аналогично cURL) и имеет проблему с ответом сервера. Либо это, либо мое понимание RFC для HTTP 1.1 и chunked данных.

Что я вижу в блочной данные должны быть в следующем формате:

4\r\n 
Wiki\r\n 
5\r\n 
pedia\r\n 
e\r\n 
in\r\n\r\nchunks.\r\n 
0\r\n 
\r\n 

то, что я на самом деле наблюдаем следующие:

4\r\n 
Wiki\r\n 
5\r\n 
pedia\r\n 
e\r\n 
in\r\n\r\nchunks.\r\n 
0 

Другими словами, несколько серверов I 'испытал с отправкой больше данных после 0 .. не CRLF, а тем более CRLFCRLF.

Как мы должны знать, что это конец фрагментированных данных без правильного формата фрагментированных тегов? Тайм-ауты случаются, глядя на CRLF после 0, и этого недостаточно.

Answer 1

Используйте Content-Length, определенно каждый раз, когда я это знаю; для загрузки файлов проверка размера файла незначительна с точки зрения ресурсов. Для передачи пакетов мы не просматриваем тело сообщения для пары CRLF. Сначала он считывает указанное количество байтов, а затем считывает еще два байта, чтобы подтвердить, что они CR и LF. Если это не так, тело сообщения плохо сформировано, и либо размер был указан неправильно, либо данные были повреждены.

Для получения более подробной информации читайте RCF, который говорит

Сервер, с использованием блочной кодирования передачи в ответ НЕ ДОЛЖЕН использовать прицеп для любых полей заголовка, если по крайней мере один из следующих не верно:

a) запрос включал поле заголовка TE, которое указывает, что «прицепы» - это , приемлемые в передаточном кодировании ответа, как описано в разделе , раздел 14.39; или,

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

способ определить длину тела сообщения:

Если заголовок имеет Transfer-Encoding и поблочного является окончательным кодирование, то длина тела сообщения определяется путем считывания и декодирования фрагментов данных, пока кодирование передачи не указывает на то, данные завершены.

Если заголовок имеет Transfer-Encoding, а передача каналов не является окончательным, то длина тела сообщения определяется путем считывания соединения до его закрытия сервером.

Если заголовок имеет передаточное кодирование в запросе, а передача каналов - окончательное кодирование, то длина сообщения не может быть надежно определена; сервер ДОЛЖЕН ответить с кодом состояния 400 (Bad Request), а затем закрыть соединение.

Если сообщение получено как с полем заголовка Transfer-Encoding, так и с Content-Length, Transfer-Encoding переопределяет Content-Length. Такое сообщение может указывать на попытку выполнить рассылку ответа запроса и должно быть обработано как ошибка. Отправитель ДОЛЖЕН удалить полученное поле Content-Length перед пересылкой такого сообщения вниз по течению.