Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Сети > ответ на HTTP запрос

Автор: froex 17.4.2009, 08:47

Посылаю http-запрос на сервер. В ответе получаю ответ следующего вида: Код HTTP/1.1 200 OK Server: nginx Date: Fri, 17 Apr 2009 05:27:52 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.2.6 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 17 Apr 2009 05:27:52 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache f60 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"    "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> ........ Во-первых, мне не нравится, что не прислали content-length. Можно ли составить запрос таким образом, чтобы content-length прислали в ответе? Во-вторых, обратите внимание на символы "f60" перед принятым исходным кодом страницы. Что эти символы означают? Для разных web-страниц эти символы тоже разные.

Автор: azesmcar 17.4.2009, 08:59

Цитата 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.        Content-Length    = "Content-Length" ":" 1*DIGIT An example is        Content-Length: 3495 Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4. Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given. Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules in section 4.4.  вот так получать длину, если ее не отправили..тут описан случай когда сервер "НЕ ДОЛЖЕН" посылать Content-Length Цитата 4.4 Message Length The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence): 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. 2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection. 3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding      header field is present). If a message is received with both a      Transfer-Encoding header field and a Content-Length header field,      the latter MUST be ignored. 4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.        A range header might be forwarded by a 1.0 proxy that does not        understand multipart/byteranges; in this case the server MUST        delimit the message using methods defined in items 1,3 or 5 of        this section. 5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length. All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

Автор: froex 17.4.2009, 09:08

спасибо. А про те три символа не знаете ничего?

Автор: azesmcar 17.4.2009, 09:18

Цитата А про те три символа не знаете ничего?  Там  должны быть только заголовки в формате MIME. Кто возвращяет страницу на сервере? Скрипт какой-то? Может он заголовки попортил? Попробуйте запросить у сервера простой HTML. Какой будет результат? Добавлено через 2 минуты и 28 секунд Нет нет..кажется понимаю..это похоже на http://en.wikipedia.org/wiki/Byte-order_mark Файл у вас UTF8?

Автор: froex 17.4.2009, 09:22

HTTP 1.0 - тех символов нет HTTP 1.1 - те символы присутствуют

Автор: azesmcar 17.4.2009, 09:27

froex Можете попробовать с файлов в кодировке ANSI на HTTP 1.1?

Автор: froex 17.4.2009, 09:36

Цитата Нет нет..кажется понимаю..это похоже на BOM Файл у вас UTF8? да, файл UTF-8. Насчет BOM - не совсем понял. Цитата Можете попробовать с файлов в кодировке ANSI на HTTP 1.1? тоже не понял.

Автор: azesmcar 17.4.2009, 09:42

froex Там ссылка http://en.wikipedia.org/wiki/Byte-order_mark BOM - Byte order mark. хранится в начале файла, хранит информацию о кодировке Юникода.  Побольше информации, ОС Сервера, какой сервер и желательно файл в студию.

Автор: froex 17.4.2009, 09:48

Цитата(azesmcar @  17.4.2009,  09:42 ) ОС Сервера, какой сервер и желательно файл в студию.  Сервер на линуксе стоит. Какой сервер точно не знаю. Файл? Да любой файл web-страницы любого сайта. У меня для всех эти символы выводятся. Иногда f60, иногда c57.

Автор: azesmcar 17.4.2009, 10:01

froex Про BOM Цитата При сохранении файла многие текстовые редакторы предлагают флажок «Include Unicode Signature (BOM)», «Add Byte Order Mark» или нечто подобное. Прежде всего убедитесь, что в вашем редакторе это есть. Если похожей настройки не обнаружено (как, например, в «Блокноте») — пользоваться таким редактором для серьёзных задач не стóит. Найдя этот флажок — отключите его. Byte Order Mark (BOM) — это три служебных байта, которые автоматически записываются в начало документа и обозначают, что он сохранён в кодировке UTF. Подробности можно прочитать в справочнике, а практическая сторона заключается в том, что эти служебные байты в UTF‑8 не являются необходимыми, зато, наоборот, могут ввести в заблуждение некоторые старые браузеры и другие программы. Добавлено через 24 секунды уберите БОМ из файла..все должно работать нормально

Автор: froex 17.4.2009, 10:03

Цитата(azesmcar @  17.4.2009,  10:01 ) Прежде всего убедитесь, что в вашем редакторе это есть Я принимаю ответ на char*, после чего вывожу в терминал. Редактора нет.

Автор: azesmcar 17.4.2009, 10:05

Цитата Я принимаю ответ на char*, после чего вывожу в терминал. Редактора нет.  Речь идет о редакторе которым сохранялся файл, которые вы открываете на сервере. к примеру вы запрашиваете http://localhost/index.html Откройте index.html и уберите из него БОМ. Поищите в настройках редактора которым открываете, если нет, пришлите файл мне, я уберу - проверим.

Автор: froex 17.4.2009, 10:13

В самом файле этих символов нету. А когда запрашиваю страницу с помощью GET-запроса, то символы появляются.

Автор: azesmcar 17.4.2009, 10:18

froex А как проверял что их нет? в редакторе? Так их и не будет, они не видимы. Откройте в HEX редакторе. И все таки - файл можно посмотреть? Я его у вас уже 4-ый пост выпрашиваю. Что я могу сказать если вы мне информацию не даете..

Автор: froex 17.4.2009, 10:28

Цитата(azesmcar @  17.4.2009,  10:18 ) А как проверял что их нет? в редакторе? Так их и не будет, они не видимы. Откройте в HEX редакторе. редактор Vim Цитата(azesmcar @  17.4.2009,  10:18 ) И все таки - файл можно посмотреть? Я его у вас уже 4-ый пост выпрашиваю. Что я могу сказать если вы мне информацию не даете..  У меня файла нет. Посмотрите, например, php.net/index.php - там d5e символы.

Автор: azesmcar 17.4.2009, 10:34

Проверьте эти два файла http://217.73.200.72/hello.php - тут нет БОМ http://217.73.200.72/hello_bom.php - тут есть результат в студию

Автор: froex 17.4.2009, 10:38

для hello.php: Код HTTP/1.1 200 OK Date: Fri, 17 Apr 2009 07:33:15 GMT Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.8g PHP/5.2.5 X-Powered-By: PHP/5.2.5 Content-Length: 19 Content-Type: text/html привет мир для hello_bom.php: Код HTTP/1.1 200 OK Date: Fri, 17 Apr 2009 07:34:09 GMT Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.8g PHP/5.2.5 X-Powered-By: PHP/5.2.5 Content-Length: 22 Content-Type: text/html привет мир во втором случае перед "привет мир" есть пробел.

Автор: azesmcar 17.4.2009, 10:40

froex 22-19=3 - это БОМ. Просто браузер его игнорирует и не показывает. Вам надо делать тоже самое. Добавлено через 50 секунд Цитата Никаких лишних символов нет. а пробел это не лишний символ? учитывая что в файлах написано абсолютно тоже самое. Добавлено через 3 минуты и 4 секунды Еще я бы проверил снифером что получает браузер при запросе на эти сайты (php.net например)

Автор: froex 17.4.2009, 10:44

Значит, эти символы нужны только для опознания кодировки UTF? Ничего страшного не будет, если я их игнорирую просто? Я думаю, что проблема решена. Спасибо.

Автор: azesmcar 17.4.2009, 10:48

froex ничего страшного, конкретно для UTF8 они вообще не нужны и ничего не означают кроме как - что файл в кодировке UTF8. Там должна быть константа EF BB BF. Почему конкретно в этом случае пробел, в случае с php.net какие-то символы сказать сложно. Может разница в версиях сервера, как они распознают БОМ. Надо бы снифером посмотреть чтобы быть уверенным. Добавлено через 1 минуту и 28 секунд Цитата Я думаю, что проблема решена. Спасибо.  пожалуйста - удачи

Автор: froex 17.4.2009, 10:50

Цитата(azesmcar @  17.4.2009,  10:48 ) Надо бы снифером посмотреть чтобы быть уверенным.  Я со сниферами не работал. Не подскажете для Debian GNU/Linux? Как-нибудь тогда посмотрю, чем отличаются они.

Автор: azesmcar 17.4.2009, 10:52

froex Wireshark http://www.wireshark.org/

Автор: froex 17.4.2009, 10:58

Спасибо за все.

Автор: phprus 17.4.2009, 17:53

azesmcar,  Цитата(azesmcar @  17.4.2009,  09:18 ) Нет нет..кажется понимаю..это похоже на BOM Файл у вас UTF8? Это не BOM и вообще эти символы к кодировке никакого отношения не имеют. Эти символы часть протокола HTTP 1.1. froex,  Цитата(froex @  17.4.2009,  08:47 ) Transfer-Encoding: chunked Connection: keep-alive Согласно этим заголовкам используется режим  keep-alive, те через одно соединение можно будет отправить более одного HTTP-запроса. Судя по отсутствию Content-Length сервер на момент начала отдачи файла не знает его длину, по этому он вынужден посылать данные по кусочкам и как-то об этом информировать клиента. Что-бы клиент понял что данные ему шлют по кускам сервер высылает заголовок Transfer-Encoding: chunked, а эти дополнительные символы появляются для того чтобы клиент мог эти куски опознавать и определить конец передачи данных. Подробнее все это описано в описании протокола HTTP 1.1. Цитата(froex @  17.4.2009,  10:44 ) Ничего страшного не будет, если я их игнорирую просто? Будет, так как, если мне память не изменяет, эти символы могу и посреди HTMLя всплыть.

Автор: froex 18.4.2009, 21:22

Ммм... и на этом спасибо. Сейчас документацию буду читать.

Автор: azesmcar 19.4.2009, 17:57

Цитата Это не BOM и вообще эти символы к кодировке никакого отношения не имеют. Эти символы часть протокола HTTP 1.1. Возможно, это было только предположение (но вправду похоже  ) Цитата Будет, так как, если мне память не изменяет, эти символы могу и посреди HTMLя всплыть. Да, но тогда они не проигнорируются..хотя надо протокол полностью изучить перед тем как работать с ним..а то мали ли что еще всплывет.. www.ietf.org поможет

Автор: froex 19.4.2009, 18:18

Цитата(azesmcar @  19.4.2009,  17:57 ) Цитата Это не BOM и вообще эти символы к кодировке никакого отношения не имеют. Эти символы часть протокола HTTP 1.1. Возможно, это было только предположение (но вправду похоже smile ) BOM ведь всегда один и тот же? Тем более его я не видел, когда ты давал проверять, а когда смотрел на всех сайтах - три символа было видно. Цитата(azesmcar @  19.4.2009,  17:57 ) www.ietf.org поможет  Почитаю на днях, опять же.

Автор: azesmcar 19.4.2009, 18:38

Цитата BOM ведь всегда один и тот же? Тем более его я не видел, когда ты давал проверять, а когда смотрел на всех сайтах - три символа было видно. Да, но Content-Length различался на три байта. Впрочем уверенности у меня как небыло, так и нет   это было всего лишь предположение..

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)