1.1 в отличии от 1.0 незакрывает сокет после ответа на запрос.Так как тогда в 1.1 отловить момент когда нужно прекращать прием данных?
2 _nic ну там много различий. Тут всё делов в двух вещах: поле Connect каторое ты передаешь. Там ты можешь сказать Keep-alive или close Первое типа остаться на линии, а второе - типа чтобы сервак закрыл соединение после отправки данных. Вторая фишка - сервак отвечает и в его ответе почти всегда есть Content-Length в котором написано сколько данных он должен передать тебе. Вот и считывай это кол-во )
Если в отдельных случаях с блоками осиливать вручную лень - лучше юзать 1.0. В реальных условиях keep-alive редко, когда может пригодиться.
keep-alive юзается когда в один контекст посылаются несколько последовательных запросов. Такое любят делать с проксями браузеры типа FF.
slesh, что тогда означает поле Keep-Alive: 300, и почему в большинстве случаев именно 300, а не какое-нибудь другое значение?
Keep-Alive. Заголовок Keep-Alive содержит значение, которое означает в течение какого времени в секундах будет удерживаться соединение. Этот заголовок следует отправлять только в том случае, если заголовок Connection содержит значение keep-alive. Поддерживается только для протокола HTTP версии 1.1. В нашем примере этот заголовок содержит значение 300, т.е. браузер сообщает серверу, что намерен удерживать постоянное соединение с сервером в течение 300 секунд.
Слушайте, меня интересует следующие: 1) Как реализовать работу программы, если используешь Keep-Alive, но при этом сервак не передал значение Content-Length (количество отправленных байтов)? 2) Если принял все данные, как реализовать паузу (те же 300 сек.), оставаясь на линии, но при том, что бы программа не зависала от ожидания?
1) а) 0D 0A (в отсутствии content-length) б) читать блоки, пока блок не станет меньше его размера (в отсутствии content-length) 2) - Буфер - Три процедуры (открытие-коннект, работа с буфером, закрытие) - Thread
dvion, что ты имеешь здесь ввиду: Ну и: Не исключено, что все блоки будут одинакового размера. Или же наоборот: сервер будет отправлять блоки разного размера. (по 1024 байт, 2048 и т. д.)
Keep-Alive - это поле указывает на не разрываное соединение, напиример "Connection: kerep-alive". и период соединения: "Keep-alvive: 300" а ваще найдите статью на википедии про HTTP - заголовки ))) там есть все))) особенно про Referer и User-Agent)
Chrome~, 0D 0A - идентификационная последовательность байт, который сведетельствует об окончании передачи. Только не нужно забывать про тайм-аут, а то до конца дней будешь эту связку байт ждать :-D Ну дык, надо организовать буфер, иначе отдельный поток на работу, через winsock, например. Он будет штундировать, пока не нарвётся на тайм-аут, например. Или не получит 0D 0A, или не упрётся носом в content-length. В потоке организовываешь саму работу с сокетом, а в классе реализации сокета уже всякими штуками промышляешь. Может скинуть самую успешную, на мой взгляд, реализацию этих дел? Собсно - вот: http://www.ararat.cz/synapse/ Лучше - не видал! И посмотреть в сорцах можно всё, что требуется)
