Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Сети";
Текущий архив: 2007.05.13;
Скачать: [xml.tar.bz2];

Вниз

Вопрос про принцип работы 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]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [29]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [30]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [31]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [32]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [33]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [34]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [35]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [36]

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


 
Anatoly Podgoretsky ©   (2006-11-11 09:57) [37]

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


 
atruhin ©   (2006-11-11 10:11) [38]

> [37] Anatoly Podgoretsky ©   (11.11.06 09:57)

Еще пару раз, чтоб понятнее было.


 
SergP ©   (2006-11-11 12:43) [39]

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


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

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


 
Anatoly Podgoretsky ©   (2006-11-11 13:55) [40]

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

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

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

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


 
Anatoly Podgoretsky ©   (2006-11-11 14:02) [41]

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

Я ночью много написал, но все пропало, повторять не охота.
В кратче все регламентируется RFC остальное фантазии.
Если коротко, то заголовок от данных отделяется одной пустой строкой и сообщение заканчивается точкой.


 
DVM ©   (2006-11-11 16:26) [42]

CRLF - не надо называть пустой строкой. Т.к. в терминах Delphi это далеко не пустая строка.


 
Anatoly Podgoretsky ©   (2006-11-11 16:48) [43]

> DVM  (11.11.2006 16:26:42)  [42]

А серверам плевать, что там Дельфи считает и что/кто это такое.


 
SergP ©   (2006-11-12 09:54) [44]

> [42] DVM ©   (11.11.06 16:26)
> CRLF - не надо называть пустой строкой. Т.к. в терминах
> Delphi это далеко не пустая строка.


Это в терминах Дельфи..., которые на данный момент к сабжу не особо имеют отношение.



Страницы: 1 2 вся ветка

Форум: "Сети";
Текущий архив: 2007.05.13;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.57 MB
Время: 0.045 c
2-1177306193
_Anton_
2007-04-23 09:29
2007.05.13
поднять окно в MDI


2-1176976563
npu3pak
2007-04-19 13:56
2007.05.13
Запись в лог-файл из TMemo


15-1176384751
botvin
2007-04-12 17:32
2007.05.13
Менеджер памяти


15-1176706494
DVM
2007-04-16 10:54
2007.05.13
Вопрос по энергосбережению и экранной заставке. Проблема.


1-1173776106
Demondelphi
2007-03-13 11:55
2007.05.13
Буфер обмена, обмен данными между главной и дочерними формами





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский