Как найти заголовок в текстовых протоколах?

Считывать побайтово пока не встречу \r\n\r\n?

Я бы так и делал. Только читал бы не побайтово, а большими порциями.

Читай неблокирующим read'ом столько сколько читается и ищи в потоке \r\n\r\n

Читай неблокирующим read'ом

С чего вы взяли, что ТСу именно неблокирующий надо?

ищи в потоке \r\n\r\n

Ну да, а Content-Length, charset, cookie и т д - это типа совсем не надо парсить, ага. Ладно ещё не нарвётесь на HTTP/0.NN, где двойной пустой строки вообще нет.

принято заводить под это дело отдельный буфер,
куда дописываются полученные байты,
после чего данные сплитятся на \n(\r), и заганяютя в список,
а уже в списке ищутся нужные данные, будь то контент длинна или еще что то
это в простом варианте

Использовать готовый парсер.

побайтово считывать медленно

И ты, мешок с костями, ещё рассуждаешь о медленности?

По теме: сообщение (запрос) состоит из элементарных сообщений (строка до разделителя), которые могут быть статусом, выражением или данным.

Раз в определении присутствует байт (конец строки), то да - считыать побайтно.

Если бы байт не упоминался, то нижней границей было бы элементарное сообщение.

С чего вы взяли, что ТСу именно неблокирующий надо?

С того что он не хочет читать по одному байту. С блокирующим только так.

С того что он не хочет читать по одному байту. С блокирующим только так.

ioctl(socket, FIONREAD, &ready_for_read);

А каким выбрать размер порции? В этом загвоздка

Я беру размер 512 байт, а если весь ответ меньше? У меня read будет висеть и ждать

Не понял, что мне мешает сделать

read(sock, buffer, 1)?

Раз в определении присутствует байт

В определении моем, которое я дал? Я мог и фигню сморозить. мне интересно как люди читают http, необязательно побайтно

Какие то монстры в ответе гугла

И по сколько считывать? Что делать если ответ меньше чем порция для считывания и сокет блокирующий?

Это зависит от того, с помощью каких функций/библиотек ты работаешь с сетью. Я могу подсказать, как это делается на c++/Qt или c++/Boost.asio .

Что делать если ответ меньше чем порция для считывания и сокет блокирующий?

recv() прочитает и вернет количество прочитанных байт. Блокироваться не будет

http://man7.org/linux/man-pages/man2/recv.2.html

These calls return the number of bytes received, or -1 if an error occurred.

Логика немного сложнее, если данных пришло больше буфера. Нужно вычитывать до тех пор пока recv() > 0.

Ничто не мешает. Это неэффективно. Слишком много сисколов.

linux-only хак. Я бы руки вырвал за такой код.

If no messages are available at the socket, the receive calls wait
       for a message to arrive, unless the socket is nonblocking

И с чего это не должен блокироваться блокирующий сокет ?

linux-only хак.

Нет, этот ioctl-код был, когда Linux-а ещё не было. Тогда даже сети не было, использовался для узнавания, сколько можно прочитать чего-либо (то есть в основном из tty).

Вот замечательный пример. https://github.com/nodejs/http-parser

Используй так длина Content-Length: = 16

char *ptr = strstr ( buf, "Content-Length:" );
ptr += 17;
int length = atoi ( ptr );

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

Понятие «протокол» подразумевает как раз свод правил, которых будут придерживаться машины при обмене данными. В твоём случае, конечно, нужно опираться на протокол, а это значит, что получив знание о том по какому протоколу к тебе обратились ты уже принимаешь решение как интерпретировать всё остальное. Представь, что нет никакой универсальной последовательности байт, которую всегда можно интерпретировать как «всё, вот тут конец», всё зависит от протокола и в данном случае конец - это «\r\n\r\n», а также как тут выже сказали, бывают и другие вариации протокола HTTP и уже тебе решать будет ли твой софт его поддерживать.

Если нужно парсить конкретно HTTP, то используй https://github.com/nodejs/http-parser

Читай неблокирующим read'ом столько сколько читается и ищи в потоке \r\n\r\n

А так как всегда есть шанс, что данные будут приходить по одному байту, то нужно будет реализовывать конечный автомат или использовать уже готовый http-parser, который уже отлажен и работает так же быстро, как собственный велосипед.

принято заводить под это дело отдельный буфер,

куда дописываются полученные байты, после чего данные сплитятся на \n(\r), и заганяютя в список, а уже в списке ищутся нужные данные, будь то контент длинна или еще что то это в простом варианте

Или можно реализовать конечный автомат, который будет анализировать входящий поток побайтно и никуда его не сохранять. Или использовать готовый http-parser.