Получение текста в TServerSocket

← →
LostCodder © (2005-09-12 17:33) [0]

Пишу сервер на TServerSocket.
Мне нужно полуить текст от клиента (от веб-браузера). Но я точно не знаю размер данных, которые должны прийти. Говорят, что метод ReceiveText может вернуть не полное содержание буфера. Как же тогда получить текст полностью?

← →
Reindeer Moss Eater © (2005-09-12 17:39) [1]

Читать надо основываясь на соглашениях протокола HTTP.
Заголовок запроса имеет ограничитель - две пустых строки.
В нем дополнительно может быть указана длина последующего контента.

← →
Digitman © (2005-09-12 17:41) [2]

аккумулировать результаты последовательных вызовов ReceiveText().

← →
LostCodder © (2005-09-12 18:27) [3]

> Читать надо основываясь на соглашениях протокола HTTP.
> Заголовок запроса имеет ограничитель - две пустых строки.
> В нем дополнительно может быть указана длина последующего
> контента.

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

> аккумулировать результаты последовательных вызовов ReceiveText().

А можете пример кода привести?

← →
atruhin © (2005-09-12 20:40) [4]

Реализация анализа HTTP протокола занимает не одну сотню строк кода. Поэтому вряд ли кто тебе даст полный код. Смотри RFC

← →
LostCodder © (2005-09-12 21:27) [5]

спецификация протокола HTTP тут не поможет..

← →
Ivane (2005-09-12 21:44) [6]

Хорошо, народ... тогда построим вопрос так:
я творю сервер(протокол DC). Ситуация впринципе такая же, как и у уважаемого LostCodder`а. Но, дело в том, что я могу парсить входящий траффик только на отдельные комманды и когда они закончатся, я не знаю(пользователь может хоть месяц сидеть на серваке). И собственно проблема в том, что в рамках того же соединения мне может понадобится отослать клиенту данные, а при одновременной попытке прочитать и отослать возникает ошибка. Соответственно было бы неплохо узнать какую-нибудь процедурку, которая хотябы возвращала: пуст буфер или нет?
З.Ы.: Я использую компонент TidTCPClient

← →
atruhin © (2005-09-13 06:59) [7]

>>LostCodder © (12.09.05 21:27) [5]
>>спецификация протокола HTTP тут не поможет..
Это почему же? Она позволяет абсолютно точно определить окончание запроса. Лично я определял без проблем. :)
>> когда они закончатся, я не знаю
А вот это плохо, нужно знать. HTTP работает в режиме запрос ответ. Т.е. принимаешь данные, определяешь окончание запроса, и начинаешь передачу ответа. Заполненность буфера тут не поможет, т.к. в спецификации HTTP1.1 клиент может слитно передавать несколько запросов подряд, не дожидаясь ответа, сервер должен отвечать в таком же порядке.
>> а при одновременной попытке прочитать и отослать возникает ошибка.
Какая ошибка? Это мы сами должны догадаться?

← →
Ozone © (2005-09-13 08:06) [8]

> [6] Ivane (12.09.05 21:44)

Копай в сторону неблокирующих сокетов.

← →
SergP © (2005-09-13 09:30) [9]

> т.к. в спецификации HTTP1.1 клиент может слитно передавать
> несколько запросов подряд, не дожидаясь ответа, сервер должен
> отвечать в таком же порядке

Интерестно, что получится если сервер на первый запрос ответит
connection: close
а уже поздно - было отправлено слитно несколько запросов...
Проигнорирует остальные?

← →
LostCodder © (2005-09-13 16:24) [10]

> Это почему же? Она позволяет абсолютно точно определить
> окончание запроса. Лично я определял без проблем. :)

можешь кратко сказать, как определить?

Запрос клиента кончается пустой строкой.
В запросе может быть дополнительно указана длина последующего контента.

>>Интерестно, что получится если сервер на первый запрос ответит
>>connection: close
>>а уже поздно - было отправлено слитно несколько запросов...
>>Проигнорирует остальные?
Несовсем. Вначале клиент посылает один запрос с Keep-Alive и если в ответе сервер, а также вся цепочка прокси, подтверждает поддержку Keep-Alive, тогда клиент может начинать посылать запросы без ожидания ответа.

>>можешь кратко сказать, как определить?
>>Запрос клиента кончается пустой строкой.
Да. Т.е. #13#10#13#10
Далее выдержка из RFC:
Если присутствует поле заголовка Transfer-Encoding (раздел 13.40) и указано, что использовано по фрагментное
("chunked") транспортное кодирование, тогда длина тела определяется выбранной схемой кодирования (раздел 2.6).
Если присутствует поле заголовка Content-Length (раздел 13.14), его значение в байтах и определяет длину тела
сообщения.

Правда в запросе клиента я Transfer-Encoding не встречал, но протокол допускает.

← →
SergP. (2005-09-14 10:55) [14]

> Несовсем. Вначале клиент посылает один запрос с Keep-Alive
> и если в ответе сервер, а также вся цепочка прокси, подтверждает
> поддержку Keep-Alive, тогда клиент может начинать посылать
> запросы без ожидания ответа.

Хорошо. А как клиент должен резать контент на части, если он послал слитно кучу запросов, а после принимает весь контент? По Content-Length?
Если так, то ведь можно послать такой запрос, на который сервер не сможет выдать Content-Length

Получение текста в TServerSocket Найти похожие ветки