Я пишу парсер HTTP для прозрачного прокси. Что меня ставит в тупик, так это Trailer:, упомянутое в спецификациях для Transfer-Encoding: chunked. На что это похоже?
Обычно HTTP-фрагмент заканчивается так.
0\r\n
\r\n
Что меня смущает, так это то, как определить конец фрагмента, если есть какие-то конечные заголовки...
ОБНОВЛЕНИЕ: я считаю, что простого \r\n\r\n, т. е. пустой строки, достаточно, чтобы определить конец конечных заголовков... Это правильно?
Ниже приведена копия примера трейлера, который я скопировал с сайта TCP/IP Guide. . 
Как мы видим, если мы хотим использовать заголовок трейлера, нам нужно добавить поле заголовка «Trailer:header_name» с именем заголовка, а затем добавить объект заголовка трейлера после фрагментированной области тела.
Мы можем добавить 0 или более заголовков трейлеров в тело HTTP в соответствии с RFC. Раздел 4.1.2 RFC7230 запрещает использование следующих заголовков в конце заголовка. область:
Отправитель НЕ ДОЛЖЕН генерировать трейлер, который содержит поле, необходимое для кадрирования сообщения (например, Transfer-Encoding и Content-Length), маршрутизации (например, Host), модификаторов запроса (например, элементы управления и условия в разделе 5 RFC7231), аутентификация (например, см. RFC7235 и RFC6265), данные управления ответом ( например, см. раздел 7.1 RFC7231), или определение того, как обрабатывать полезную нагрузку (например, Content- Кодирование, Content-Type, Content-Range и Trailer).
Это означает, что мы можем использовать другие стандартные заголовки и пользовательские заголовки в области заголовка трейлера.
28 <html><body><p>The file you requested is и 21 bytes long and was last modified:
- person slinkin; 17.02.2021
0\r\n
SomeAfterHeader: TheData \r\n
\r\n
Другими словами, достаточно найти \r\n\r\n, говоря простым языком: пустую строку. Чтобы обнаружить конец передачи, разделенной на фрагменты. Но очень важно, чтобы каждый фрагмент был прочитан, прежде чем делать это. Поскольку сами данные, разбитые на фрагменты, могут содержать пустые строки, которые ошибочно будут обнаружены как конец потока.
Относительно трейлера:
Как вы заметили, список конечных заголовков должен быть указан в заголовке Trailer.
BNF в Раздел 14.40 RFC 2616 выглядит следующим образом:
Trailer = "Trailer" ":" 1#field-name
Гурли и Тотти приводят такой пример:
Trailer: Content-Length
(Странно, что они приводят этот пример, поскольку Content-Length явно запрещено быть конечным заголовком в 14.40.)
Шифлетт приводит такой пример:
Trailer: Date
Что касается конца сообщения с завершающими заголовками:
BNF в разделе 3.6.1 RFC 2616 — это то, что вы находясь в поиске. Вот часть:
Chunked-Body = *chunk
last-chunk
trailer
CRLF
last-chunk = 1*("0") [ chunk-extension ] CRLF
trailer = *(entity-header CRLF)
Таким образом, последний фрагмент и 2 завершающих заголовка могут выглядеть так:
0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>
