Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

SergP. (2005-09-14 10:55:00) [1]

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

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

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

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

atruhin (2005-09-13 16:47:00) [3]
>>Интерестно, что получится если сервер на первый запрос ответит
>>connection: close
>>а уже поздно - было отправлено слитно несколько запросов...
>>Проигнорирует остальные?
Несовсем. Вначале клиент посылает один запрос с Keep-Alive и если в ответе сервер, а также вся цепочка прокси, подтверждает поддержку Keep-Alive, тогда клиент может начинать посылать запросы без ожидания ответа.

Reindeer Moss Eater (2005-09-13 16:32:00) [4]
Запрос клиента кончается пустой строкой.
В запросе может быть дополнительно указана длина последующего контента.

LostCodder (2005-09-13 16:24:00) [5]

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

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

SergP (2005-09-13 09:30:00) [6]

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

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

Ozone (2005-09-13 08:06:00) [7]
> [6] Ivane (12.09.05 21:44)

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

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

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

LostCodder (2005-09-12 21:27:00) [10]
спецификация протокола HTTP тут не поможет..

atruhin (2005-09-12 20:40:00) [11]
Реализация анализа HTTP протокола занимает не одну сотню строк кода. Поэтому вряд ли кто тебе даст полный код. Смотри RFC

LostCodder (2005-09-12 18:27:00) [12]

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

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

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

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

Digitman (2005-09-12 17:41:00) [13]
аккумулировать результаты последовательных вызовов ReceiveText().

Reindeer Moss Eater (2005-09-12 17:39:00) [14]
Читать надо основываясь на соглашениях протокола HTTP.
Заголовок запроса имеет ограничитель - две пустых строки.
В нем дополнительно может быть указана длина последующего контента.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »