Вопрос про принцип работы HTTP

← →
Суслик © (2006-11-11 01:11) [0]

Здравствуйте!

1. Вводная.
Принимая на *стороне сервера* запрос TCP нужно быть готовым, что он прийдет не весь сразу, а частями. Это факт. Когда когда-то я писал свои тестовые сервера (в целях изучения) я применял следующий протокол:
а) мой сервер ждал 4 байта - длина сообщения.
б) после получения четырех байт - сервер читал сообщения, с учетом того, что сообщение может прийти не сразу.

2. Вопрос.
Сейчас я начал разбираться с HTTP.
Это вроде текстовый протокол. Делаю я это так - с помощью TIdTCPServer ловлю все, что мне посылает браузер.
Насколько я понял, HTTP - это чисто протокол. Я не смог заметить, что каким-то образом передается длина сообщения.

Вопрос
Как сервер HTTP понимает сколько же ему читать из сокета?

PS. Прошу прощения за ламерский вопрос :)

← →
Суслик © (2006-11-11 01:15) [1]

PS.
Я посмотрел Таненбаума - он про HTTP просто говорит - это текстовый протокол (что такое текстовый протокол я у него в книге не нашел).
Смотрел также Стивенса - он вообще мало говорит про HTTP, т.к. книги похоже старая достаточно.

Так что, если можно, то объясните новичку в сетях :)

← →
Eraser © (2006-11-11 01:26) [2]

> [1] Суслик © (11.11.06 01:15)

RFC надо было смотреть )
так как текста много, то можно и русскую версию http://www.lib.ru/WEBMASTER/rfc2068/
> [0] Суслик © (11.11.06 01:11)

тут почти один и тот же ответ на 1 и 2 вопросы.
4.4 Длина сообщения. 1. Когда тело сообщения (message-body) присутствует в сообщении, длина этого тела определяется одним из следующих методов (в порядке старшинства): Любое сообщение ответа, которое НЕ ДОЛЖНО включать тело сообщения (message-body) (например ответы с кодами состояния 1xx, 204, 304 и все ответы на запрос HEAD) всегда завершается пустой строкой после полей заголовка, независимо от полей заголовка объекта (entity-header fields), представленных в сообщении. 2. Если поле заголовка Transfer-Encoding (раздел 14.40) присутствует и указывает на применение кодирования передачи "chunked", то длина определяется кодированием по кускам (chunked encoding) (раздел 3.6). 3. Если поле заголовка Content-Length (раздел 14.14) присутствует, то его значение представляет длину тела сообщения (message-body) в байтах. 4. Если сообщение использует медиа тип "multipart/byteranges", который саморазграничен, то он и определяет длину. Этот медиа тип НЕ ДОЛЖЕН использоваться, если отправитель не знает, что получатель может его обработать; присутствие в запросе заголовка Range с несколькими спецификаторами диапазонов байтов (byte-range) подразумевает, что клиент может анализировать multipart/byteranges ответы. 5. Длина определяется закрытием соединения сервером. (Закрытие соединения не может использоваться для указания конца тела запроса, так как в этом случае у сервера не остается никакой возможности послать обратно ответ).
(c) http://www.lib.ru/WEBMASTER/rfc2068/section-4.html

imho чаще всего используется 5 вариант.

> Делаю я это так - с помощью TIdTCPServer ловлю все, что
> мне посылает браузер

почему бы не использовать TIdHTTPServer?

← →
Орион © (2006-11-11 01:28) [3]

> Здравствуйте!

Вечер добрый.

> Насколько я понял, HTTP - это чисто протокол.

А есть не "чисто" протокол?

> Как сервер HTTP понимает сколько же ему читать из сокета?

Ну не путем же медитаций, верно.
По заголовкам, которые ему клиент, то бишь, браузер отсылает.

Короче говоря http://www.w3.org/Protocols/rfc2616/rfc2616.html

← →
Орион © (2006-11-11 01:29) [4]

> почему бы не использовать TIdHTTPServer?

Лучше изобрести велосипед на основе TIdTCPServer.
И в HTTP поможет разобраться и... И ну их нафиг "высокоуровневые" компоненты Indy :)

← →
Ketmar © (2006-11-11 01:38) [5]

сначала читаешь заголовки. потом ищешь там content-length. если есть -- повезло. если нет -- тупо читаешь, пока сокет не закроют.

на самом деле всё сложнее, но пока и так пойдёт. %-)

← →
Суслик © (2006-11-11 01:40) [6]

> Ketmar © (11.11.06 01:38) [5]

Я примерно в этом духе что-то и представлял - т.е. некие косвенные правла чтения.

Но вот этого я понять все равно не могу

> тупо читаешь, пока сокет не закроют.

что значит закроют?
Исходный вопрос был - как сервер определяет скильки ему читать?
Если соекет закроют, то куда он (сервер) отвечать то будет?

← →
Суслик © (2006-11-11 01:45) [7]

> Eraser © (11.11.06 01:26) [2]

Я полагаю, что на *мой* вопрос больше отвечает этот раздел http://www.lib.ru/WEBMASTER/rfc2068/section-5.html.

Вопрос тогда такой - а сколько сервер может ждать пока не поймет, что не стоит ждать и дочитывать все данные (например, потому, что клиент "отвалился" или еще почему)?

← →
Ketmar © (2006-11-11 01:48) [8]

>[6] Суслик(c) 11-Nov-2006, 01:40
>что значит закроют?
а. пардон. попутал с недосыпу клиент с сервером. %-)
если клиент не удосужился прислать content-length, читать вообще ничего не надо. такие клиенты должны умереть быстро и болезненно.

← →
Суслик © (2006-11-11 01:52) [9]

> если клиент не удосужился прислать content-length, читать
> вообще ничего не надо. такие клиенты должны умереть быстро
> и болезненно.

Ну типа, сами себя об стену :)
А все-так. IE (6) прислал моему INDY серверу это. Тут нет, упомянутого тобой content-lentgth.

GET /123 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockw ave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET C
LR 1.1.4322)
Host: 127.0.0.1:1234
Connection: Keep-Alive

← →
Ketmar © (2006-11-11 01:55) [10]

значит, это всё. больше читать ничего не надо. надо только отдавать.

← →
Суслик © (2006-11-11 01:56) [11]

> Ketmar © (11.11.06 01:55) [10]
> значит, это всё. больше читать ничего не надо. надо только
> отдавать.

Америку открыл :)

А как серверу узнать, что это "все". Ведь может еще пакет прийти.

Хоть режь меня - не могу понять, какая тут логика.

← →
Ketmar © (2006-11-11 01:58) [12]

>[11] Суслик(c) 11-Nov-2006, 01:56
>А как серверу узнать, что это "все". Ведь может еще пакет
>прийти.
какой, в пень, пакет??? заголовки заканчиваются пустой строкой. как поймал ей -- все. если есть content-length, то читаешь сколько надо. если нет -- сразу запрошеное отдаешь. просто, как выпить 100 граммов.

>Хоть режь меня - не могу понять, какая тут логика.
тебе что, дать самописный минимальный http-сервер на api? там кода мизер. %-)

← →
Eraser © (2006-11-11 01:59) [13]

> [11] Суслик © (11.11.06 01:56)

> А как серверу узнать, что это "все"

а ему и не надо узнавать, сервак должен "рубить" соединение.

← →
Суслик © (2006-11-11 02:00) [14]

> Ketmar © (11.11.06 01:58) [12]
> тебе что, дать самописный минимальный http-сервер на api?
> там кода мизер. %-)

Дай. Разберусь.
timokhov@gmail.com (только БЕЗ exe - зарежет, собака).

-----
Т.е. - пустая строка - это признак окончания запроса?

← →
Eraser © (2006-11-11 02:04) [15]

> Т.е. - пустая строка - это признак окончания запроса?

признак окончания заголовка запроса.

← →
Ketmar © (2006-11-11 02:08) [16]

>[14] Суслик(c) 11-Nov-2006, 02:00
>Дай. Разберусь.
ок. утречком пришлю (найти надо %-).

>Т.е. - пустая строка - это признак окончания запроса?
нет. окончания заголовков.

← →
Ketmar © (2006-11-11 02:09) [17]

>[15] Eraser(c) 11-Nov-2006, 02:04
>признак окончания заголовка запроса.
или ответа. %-)

← →
Суслик © (2006-11-11 02:10) [18]

> Eraser © (11.11.06 02:04) [15]

наверное, начинаю понимать - если встретился признак окончания заголовка запроса, но content-length в заголовке не встретился, то типа все - весь запрос.

Так?

← →
Суслик © (2006-11-11 02:11) [19]

> Ketmar © (11.11.06 02:08) [16]
> >[14] Суслик(c) 11-Nov-2006, 02:00
> >Дай. Разберусь.
> ок. утречком пришлю (найти надо %-).

пришли. буду рад.

← →
Eraser © (2006-11-11 02:11) [20]

> [18] Суслик © (11.11.06 02:10)

вроде так, а там кто его знает какие случаи могут быть ) уж очень пристроек всяких много у этого http.

← →
Суслик © (2006-11-11 02:16) [21]

Всем спасибо.
Покопаюсь в сервера Кетмара (который он мне уже прислал завтра).
Если появятся вопросы обязательно спрошу.

--------
Ко всем, кто советовал читать rfc.
Я переодически читаю сабж. Но сами понимаете, что дело это очень непростое, т.к. документы носят характер сугубо технический.

Согласитесь, что иногда нужно быстро понять суть, а уж потом копать детали. Данный топик был организован мною для того, чтобы быстро выяснить суть. Поэтому к rfc я обязательно обращусь, но нужно прежде понимать что к чему, хотя бы в общих чертах.

← →
Ketmar © (2006-11-11 02:33) [22]

до сих пор полные rfc ниасилил. что не мешает моему серверу отлично работать в нашей локалке. %-)

← →
Суслик © (2006-11-11 02:37) [23]

sources of your server wellcome to my email

:)

← →
Ketmar © (2006-11-11 02:52) [24]

>[23] Суслик(c) 11-Nov-2006, 02:37
>sources of your server wellcome to my email
почистить надо сначала. а то там не то что ты, я уже ничего не понимаю. потому и утром. %-)

← →
SergP © (2006-11-11 06:10) [25]

> Т.е. - пустая строка - это признак окончания запроса?

Признак окончания запроса вроде как две пустых строки.

← →
Орион © (2006-11-11 09:19) [26]

> [25] SergP © (11.11.06 06:10)

нет, одна. 2 CRLF :) (а для некоторых серверов просто 2 LF).

← →
Anatoly Podgoretsky © (2006-11-11 09:57) [27]

Удалено модератором

← →
Anatoly Podgoretsky © (2006-11-11 09:57) [28]

Удалено модератором

> [26] Орион © (11.11.06 09:19)
> > [25] SergP © (11.11.06 06:10)
>
> нет, одна. 2 CRLF :) (а для некоторых серверов просто 2
> LF).

А 2 CRLF - это типа не две пустые строки?

Ну хорошо.Тогда:
признак окончания заголовка запроса: 1 CRLF
а признак окончания запроса: 2 CRLF

> SergP (11.11.2006 12:43:39) [39]

> А 2 CRLF - это типа не две пустые строки?

Признак окончания пустая строка, в соответствии с RFC
и ничего более.

Конечно, нет, можно хоть десять, но только первая пустая строка является признаком, все остальные данными.
Тут фантазировать не надо, документ одназначно говорит и никаких двойных LF

Вопрос про принцип работы HTTP Найти похожие ветки