Помогите, пожалуйста, разобраться с таким вопросом.
Пишется парсер HTTP сообщений. В RFC 2616 HTTP 1.1 описывается метод HEAD:
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request.
При запросе HEAD получаем ответ с хедером Content-Length со значением размера тела сообщения, которое пришло бы при таком же запросе GET, но самого тела нет. То есть после прочтения хедеров не нужно читать тело, а переходить сразу к следующему сообщению.
Как распознать такой ответ, если соединение не обрывается? Как отличить его от GET?
Помогите, пожалуйста.
Здравствуйте, Gst2, Вы писали:
G>Здравствуйте.
G>Помогите, пожалуйста, разобраться с таким вопросом.
G>Пишется парсер HTTP сообщений. В RFC 2616 HTTP 1.1 описывается метод HEAD:
G> The HEAD method is identical to GET except that the server MUST NOT G> return a message-body in the response. The metainformation contained G> in the HTTP headers in response to a HEAD request SHOULD be identical G> to the information sent in response to a GET request.
G>При запросе HEAD получаем ответ с хедером Content-Length со значением размера тела сообщения, которое пришло бы при таком же запросе GET, но самого тела нет. То есть после прочтения хедеров не нужно читать тело, а переходить сразу к следующему сообщению.
G>Как распознать такой ответ, если соединение не обрывается? Как отличить его от GET?
Po pervomu slovu v zaprose, GET ili HEAD G>Помогите, пожалуйста.
G>Спасибо.
Здравствуйте, Gst2, Вы писали:
G>Здравствуйте.
G>Помогите, пожалуйста, разобраться с таким вопросом.
G>Пишется парсер HTTP сообщений. В RFC 2616 HTTP 1.1 описывается метод HEAD:
G> The HEAD method is identical to GET except that the server MUST NOT G> return a message-body in the response. The metainformation contained G> in the HTTP headers in response to a HEAD request SHOULD be identical G> to the information sent in response to a GET request.
G>При запросе HEAD получаем ответ с хедером Content-Length со значением размера тела сообщения, которое пришло бы при таком же запросе GET, но самого тела нет. То есть после прочтения хедеров не нужно читать тело, а переходить сразу к следующему сообщению.
G>Как распознать такой ответ, если соединение не обрывается? Как отличить его от GET?
по запросу HEAD
ты же можешь запомнить это. А сервер должен не включать тело — т.е. тела не будет гарантированно
I>по запросу HEAD I>ты же можешь запомнить это. А сервер должен не включать тело — т.е. тела не будет гарантированно
Простите, а что значит "по запросу HEAD"? Мне нужно распознать не запрос, а ответ на него. Нужно отличить ответ на запрос HEAD и GET. Заголовки у них идентичны.
Здравствуйте, Gst2, Вы писали:
G>Здравствуйте, ilnar, Вы писали:
I>>по запросу HEAD I>>ты же можешь запомнить это. А сервер должен не включать тело — т.е. тела не будет гарантированно
G>Простите, а что значит "по запросу HEAD"? Мне нужно распознать не запрос, а ответ на него. Нужно отличить ответ на запрос HEAD и GET. Заголовки у них идентичны.
но перед тем как получать ответ, ты же сначало шлешь запрос HEAD или GET, вот и запоминай, какой послал, а потом получай ответ соответственно
Здравствуйте, alexora, Вы писали: G>>Как распознать такой ответ, если соединение не обрывается? Как отличить его от GET? A>Po pervomu slovu v zaprose, GET ili HEAD
Нужно распознать не запрос (Request), а ответ (Response). В ответе на HEAD те же заголовки, что и на GET.
Поступила пачка сообщений, буфер передали в парсер, а он уже должен отличить одно от другого и разобрать их. Вопрос в том, как отличить ответ на запрос HEAD, от ответа на запрос GET. Это критично, так как парсер, не зная, что это ответ на HEAD, найдет хэдэр Content-Length и начнет парсить тело, которого нет.
Может кто-то разбирался с таким? Или мысли по-поводу?
Здравствуйте, ilnar, Вы писали:
I>Здравствуйте, Gst2, Вы писали:
G>>Здравствуйте, ilnar, Вы писали:
I>>>по запросу HEAD I>>>ты же можешь запомнить это. А сервер должен не включать тело — т.е. тела не будет гарантированно
G>>Простите, а что значит "по запросу HEAD"? Мне нужно распознать не запрос, а ответ на него. Нужно отличить ответ на запрос HEAD и GET. Заголовки у них идентичны.
I>но перед тем как получать ответ, ты же сначало шлешь запрос HEAD или GET, вот и запоминай, какой послал, а потом получай ответ соответственно
То есть Вы так и делали?
Просто соединение может быть постоянным, и я могу послать пачку запросов и получить от сервера такую же пачку "200 OK". Кроме того, запросы отсылает клиент, а парсер всего лишь получает прочитаный буфер. В этом буфере могут быть как запросы, так и ответы, всё, что прибежало. И если пришла пачка ответов, то кто из них ответ на HEAD?
Здравствуйте, Gst2, Вы писали:
G>То есть Вы так и делали?
у меня запрос-ответ идет синхронно, второй запрос не отсылается пока не придет ответ на первый — в этом плюс как видишь
G>Просто соединение может быть постоянным, и я могу послать пачку запросов и получить от сервера такую же пачку "200 OK". Кроме того, запросы отсылает клиент, а парсер всего лишь получает прочитаный буфер. В этом буфере могут быть как запросы, так и ответы, всё, что прибежало. И если пришла пачка ответов, то кто из них ответ на HEAD?
в этом случае можно фиксировать порядок ответов, т.е. послал N запросов — фиксируешь типы, обрабатываешь в том же порядке — порядок ответов при условии одного соединения, ИМХО, будет совпадать с порядком запросов.
или другой вариант, разделять ответы по заголовкам
правда есть шанс ошибиться, но примено с такой вероятностью ошибки парсится запрос с мултипарт содержанием.
при этом можно обезопаситься так: после заголовка идет или не идет содержимое с размером КонтентЛен — смещаешься от конца заголовка на этот размер и смотришь — если начинается другой ответ — значит с большой вероятностью у этого ответа есть содержимое, иначе — скорее всего ответа не было. Очень редко может случится, что заголовок говорит о размере, например, 300б, потом идет ответ на следующий запрос, который вместе с заголовком ровно 300б (в таких редких случаях ты просто этот или несколько запросов потеряешь). Не думаю что такое "везение" будет возникать в реальности
Здравствуйте, ilnar, Вы писали:
I>в этом случае можно фиксировать порядок ответов, т.е. послал N запросов — фиксируешь типы, обрабатываешь в том же порядке — порядок ответов при условии одного соединения, ИМХО, будет совпадать с порядком запросов.
Таки да, по спецификации они должны приходить в том же порядке, но парсер этого не знает (порядка не знает). Он просто получает прочитанные данные и разбирает их. Тогда прийдется говорить ему номер ответа на HEAD и считать, ему ответы, клиенту запросы? Просто не знаю, на сколько это нормально?
I>или другой вариант, разделять ответы по заголовкам I>правда есть шанс ошибиться, но примено с такой вероятностью ошибки парсится запрос с мултипарт содержанием. I>при этом можно обезопаситься так: после заголовка идет или не идет содержимое с размером КонтентЛен — смещаешься от конца заголовка на этот размер и смотришь — если начинается другой ответ — значит с большой вероятностью у этого ответа есть содержимое, иначе — скорее всего ответа не было. Очень редко может случится, что заголовок говорит о размере, например, 300б, потом идет ответ на следующий запрос, который вместе с заголовком ровно 300б (в таких редких случаях ты просто этот или несколько запросов потеряешь). Не думаю что такое "везение" будет возникать в реальности
Можно сделать такой "лукфорвард", и посмотреть следующую строку. Но даже, если она будет типа "<some word 1> SP <some word 2> SP <some string> CRLF", и если <some word 1> будет начинаться с "HTTP/", то как быть увереным, что это не строка хэдэра или тела? Смотреть дальше?
А если подлый сервер отправит вместо Content-Length Transfer-Encoding? Тогда размер не будет известен заранее.
Тут возник еще такой вопрос: являются ли ответы на запрос HEAD сообщениями с "a self-defined message length " (RFC 2616) ?
Здравствуйте, Gst2, Вы писали:
G>Таки да, по спецификации они должны приходить в том же порядке, но парсер этого не знает (порядка не знает). Он просто получает прочитанные данные и разбирает их. Тогда прийдется говорить ему номер ответа на HEAD и считать, ему ответы, клиенту запросы? Просто не знаю, на сколько это нормально?
А почему бы сразу парсеру не сообщать тип ответа? Ведь тот, кто шлет запросы и принимает ответы знает это наверняка. Так вот, парсеру сразу можно сказать, какой тип (HEAD или GET), а он пусть парсит.
Здравствуйте, Vadim S., Вы писали:
VS>Здравствуйте, Gst2, Вы писали:
G>>Таки да, по спецификации они должны приходить в том же порядке, но парсер этого не знает (порядка не знает). Он просто получает прочитанные данные и разбирает их. Тогда прийдется говорить ему номер ответа на HEAD и считать, ему ответы, клиенту запросы? Просто не знаю, на сколько это нормально?
VS>А почему бы сразу парсеру не сообщать тип ответа? Ведь тот, кто шлет запросы и принимает ответы знает это наверняка. Так вот, парсеру сразу можно сказать, какой тип (HEAD или GET), а он пусть парсит.
Это получается тоже самое, что и считать запросы и ответы. Если клиент через постоянное соединение отправил N запросов, и k-й -- запрос HEAD, то парсеру нужно будет передать номер запроса, а он (парсер) должен будет считать ответы. Я же говорил, что просто не знаю на сколько это хорошо. То есть такая практика обычна и нормальна?
Считать запросы и ответы мне кажется не очень хорошо, так как диапазон значений рано или поздно закончится, клиент может отправить подряд очень много запросов HEAD.
Проверять, не начинается ли новое сообщение после возможного тела, тоже не надежно, неизвестно идет ли там ответ или запрос или тело.
Что же делать ?
Как отличить ответ на HEAD от ответа на GET ??
Gst2 пишет: > Помогите, пожалуйста! > > Считать запросы и ответы мне кажется не очень хорошо, так как диапазон значений рано или поздно закончится, клиент может отправить подряд очень много запросов HEAD. > Проверять, не начинается ли новое сообщение после возможного тела, тоже не надежно, неизвестно идет ли там ответ или запрос или тело. > Что же делать ? > Как отличить ответ на HEAD от ответа на GET ??
Без контекста никак.
Номеруй. Используя unsigned long, если запрос будет каждую секунду
переполнение будет через 136 лет, если кажду 1 мс — через 49 дней.
Переполнение можно ловить или взять размерность поболее.
Здравствуйте, vortex, Вы писали:
V>Gst2 пишет: >> Помогите, пожалуйста! >> >> Считать запросы и ответы мне кажется не очень хорошо, так как диапазон значений рано или поздно закончится, клиент может отправить подряд очень много запросов HEAD. >> Проверять, не начинается ли новое сообщение после возможного тела, тоже не надежно, неизвестно идет ли там ответ или запрос или тело. >> Что же делать ? >> Как отличить ответ на HEAD от ответа на GET ??
V>Без контекста никак.
V>Номеруй. Используя unsigned long, если запрос будет каждую секунду V>переполнение будет через 136 лет, если кажду 1 мс — через 49 дней. V>Переполнение можно ловить или взять размерность поболее.
? 
??
