Сопоставление HTTP-ответов с соответствующими конвейерными HTTP-запросами.

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

Единственная проблема, которую я обнаружил, связана с конвейерными запросами. После этого я получаю несколько ответов, но я не знаю, какие пакеты являются ответом на конкретный запрос, а какие нет. Я читал в другом посте, что ответы будут приходить последовательно, и сочетание этого свойства с информацией в поле Content-Length кажется решением. Проблема в том, что Content-length не является обязательным полем, поэтому я не уверен, что всегда могу на это положиться.

Кто-нибудь знает, как на самом деле это делают веб-браузеры, которые поддерживают эту функцию (кстати, не большинство из них)?


person Javier    schedule 08.08.2011    source источник


Ответы (2)


Информация о длине тела должна присутствовать в заголовках. Это просто не всегда в «длине контента». Чтобы разобраться во всем этом, вам придется изучить соответствующий RFC 2616. В частности, в разделе 4.4 рассматриваются различные заголовки.

Еще несколько важных правил из RFC 2616:

При конвейерной обработке:
сервер ДОЛЖЕН отправлять ответы на эти запросы в том же порядке, в котором они были получены.

Начиная с 9.2
Если тело ответа не включено, ответ ДОЛЖЕН содержать поле Content-Length со значением поля "0".

Начиная с 10.2.7 206 Partial Content
Ответ ДОЛЖЕН включать .... Либо поле заголовка Content-Range ..., либо тип содержимого multipart/byteranges, включая поля Content-Range для каждого часть.

Начиная с 14.13 Content-Length
Приложения ДОЛЖНЫ использовать это поле для указания длины передачи тела сообщения, если это не запрещено правилами в разделе 4.4.

person Eddy    schedule 08.08.2011
comment
Большое спасибо Эдди! Это было очень полезно. - person Javier; 25.08.2011
comment
Для таких, как я, нужен источник поведения при конвейерной обработке, он находится в RFC 2616, 8.1.2.2 Конвейерная обработка. - person Sisyphus; 12.12.2014

Текущие ответы немного устарели. Нужно обновление.

Новый RFC для HTTP 1.1 — RFC 7230. И содержит более точную информацию о парсинге размера сообщений.

Определить размер сообщения довольно сложно. У вас может быть Content-length, или Transfer-Encoding: chunked, или оба, или ни одного. И некоторые специальные коды, такие как 100 Continue, которые могут изменить все это.

Первая ссылка содержит 7 записей, которые нужно проверить в правильном порядке, чтобы угадать правильный размер.

И, как указано в последней ссылке, неспособность определить правильную длину сообщения может привести к проблемам контрабанды HTTP (разделение, отравление кеша).

Конвейерная поддержка является источником большинства проблем с контрабандой. Вы действительно должны позаботиться обо всем документе RFC7230, если хотите его реализовать.

person regilero    schedule 14.04.2017