Неполученные HTTP запросы сервером на C++

[maks1331]

Здравствуйте! Написал веб-сервер, изначально, при обработке нескольких запросов (index.html, favicon, one js and css file) сервер получал каждый из них. Но как только колличество запросов увеличилось (index.html, favicon, one css and six js, one image) я начал замечать непонятное для меня поведение:

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

И еще, почти при каждом запросе происходит новое подключение к сокету, почему не используется уже подключенный, это какая то особенность поведения современных браузеров?

# Sun May 29 13:23:42 2022 Connection Controller : "Accept": Socket accept successful.
# Sun May 29 13:23:42 2022 Connection Controller : "HTTPProtocolAction": HTTP module: Request url: /.
# Sun May 29 13:23:42 2022 Connection Controller : "HTTPProtocolAction": HTTP module: Request url: /style.css.
# Sun May 29 13:23:42 2022 Connection Controller : "Accept": Socket accept successful.
# Sun May 29 13:23:42 2022 Connection Controller : "HTTPProtocolAction": HTTP module: Request url: /general.js.

[macomics]

Посмотрите здесь

[maks1331]

Сообщение от macomics

Посмотрите здесь

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

Про "недошедшие" запросы есть идеи?

[macomics]

Да это ссылка на описание настройки сервера Apache, но в ее описании дают понять особенности работы протоколов и отправляют в нужную сторону для разбирательств. А именно, в протоколе HTTP/1.0 необходимо дополнительно у клиента спрашивать о поддержании соединения. А в протоколе HTTP/1.1 все соединения по умолчанию keep-alive, если не указано обратное.

For HTTP/1.0 clients, Keep-Alive connections will only be used if they are specifically requested by a client. In addition, a Keep-Alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI pages, and server-generated directory listings will generally not use Keep-Alive connections to HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.

[maks1331]

Попробую покопаться, спасибо

[maks1331]

Вчера искал информацию по 1.1 HTTP протоколу, но не нашел ничего особенного.

Connection: keep-alive

или

Connection: close

В заголовке ответа разницы не даёт, разве что с первым вариантом работает чуть стабильнее.

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

[macomics]

А зачем долго искать
Или вот это

[maks1331]

Нашел вот такое:

После получения метода, подчиненного этим требованиям, от HTTP/1.1 (или более позднего) клиента, HTTP/1.1 (или более поздний) сервер ДОЛЖЕН либо ответить кодом состояния 100 (Продолжать, Continue) и продолжать чтение входного потока, либо ответить ошибочным кодом состояния. Если сервер ответил ошибочным кодом состояния, то он МОЖЕТ либо закрыть транспортное соединение (TCP), либо продолжать читать и отбрасывать оставшуюся часть запроса. Он НЕ ДОЛЖЕН выполнять запрошенный метод, если возвратил код состояния ошибки.
----
Отправка 100 Continue не исправило ситуацию

[macomics]

А вы точно правильную информацию отправляете. Проверьте

100 Continue
The client may continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client should continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server must send a final response after the request has been completed.

[maks1331]

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

pthread_attr_setscope(&attr, PTHREAD_SCOPE_PROCESS);
pthread_attr_setscope(&attr, SCHED_FIFO);
pthread_attr_setscope(&attr, PTHREAD_CREATE_DETACHED);
pthread_attr_setscope(&attr, PTHREAD_EXPLICIT_SCHED);

Запускаю поток со следующими атрибутами.