Клуб Элитных Пользователей (КЭП) Саратов - Социально-политический форум России. Политика и общественная жизнь страны. Клуб Элитных Пользователей

Клуб Элитных Пользователей (КЭП) Саратов - Социально-политический форум России. Политика и общественная жизнь страны.
Вернуться   Форум КЭП > Мир компьютера > Web технологии


Имя
Пароль

Нужна помощь ребенку!!!

Партнеры форума
-->


    Web технологии html, java, php, xml и тд. Веб сервера.

    Ответ
     
    Опции темы Опции просмотра
    Старый 11.12.2007, 13:09   #1
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    Стрелка Гипертекстный протокол HTTP

    Протокол передачи гипертекста HTTP является протоколом прикладного уровня для распределенных мультимедийных информационных систем. Это объектно-ориентированный протокол, пригодный для решения многих задач, таких как создание серверов имен, распределенных объектно-ориентированных управляющих систем и др.. Структура HTTP позволяет создавать системы, независящие от передаваемой информации.
    Протокол HTTP использован при построении глобальной информационной системы World-Wide Web (начиная с 1990).
    Первые версии, такие как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли являются последними.
    Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений сходен с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions).
    HTTP используется также в качестве базового протокола для коммуникации пользовательских агентов с прокси-серверами и другими системами Интернет, в том числе и использующие протоколы SMTP, NNTP, FTP, Gopher и Wais. Последнее обстоятельство способствует интегрированию различных служб Интернет. Ниже описаны базовые понятия и термины протокола HTTP.
    Прокси
    Промежуточная программа, которая выполняет функции, как сервера, так и клиента. Такая программа предназначена для обслуживания запросов так, как если бы это делал первичный сервер. Запросы обслуживаются внутри или переадресуются другим серверам.
    Туннель
    Промежуточная программа, которая работает как ретранслятор между двумя объектами. Туннель закрывается, когда обе стороны, соединенные им прерывают сессию. Туннель может быть активирован с помощью HTTP-запроса.
    Время пригодности объекта (expiration time)
    Время, при котором исходный сервер требует, чтобы объект не посылался более кэшем без перепроверки пригодности.
    Эвристическое значение времени жизни (heuristic expiration time)
    Время пригодности, присваиваемое объекту в кэше, если это время не задано явно.
    Возраст
    Возраст отклика - время с момента его посылки или проверки его пригодности исходным сервером.
    Время жизни (freshness lifetime)
    Продолжительность времени с момента генерации отклика до истечения его пригодности.
    Свежий
    Отклик считается свежим, если его возраст не превысил времени его пригодности.
    Устаревший
    Отклик считается устаревшим, когда его возраст превысил время жизни.
    Семантическая прозрачность
    Кэш по отношению к конкретному отклику функционирует в "семантически прозрачном" режиме, когда его использование не имеет последствий ни для исходного сервера, ни для запрашивающего клиента. Когда кэш семантически прозрачен, клиент получает в точности тот же отклик (за исключением транспортных заголовков), какой он бы получил при непосредственном обращении к исходному серверу.
    Валидатор
    Протокольный элемент (например, метка объекта или время last-modified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта.
    Метод
    Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.).


    Взаимодействие клиента, кэша и исходного сервера в протоколе HTTP


    Кэш может находиться в ЭВМ клиента или агента пользователя, но может размещаться на соседнем континенте. Число прокси между клиентом и исходным сервером может варьироваться и ограничивается сверху только здравым смыслом.




    Структура ресурса и объекта


    Протокол HTTP представляет собой протокол запросов-откликов. Клиент посылает запрос серверу в форме, определяющей метод, URI и версию протокола. В конце запроса следует MIME-подобное сообщение, содержащее модификаторы, информацию о клиенте и, возможно, другие данные. Сервер откликается, посылая статусную строку, которая включает в себя версию протокола, код результата (успех/неудача) и MIME-подобное сообщение, в котором содержатся данные о сервере и метаинформация.
    Большинство HTTP-обменов инициируются пользователем и состоят из запросов ресурсов, имеющихся на определенном сервере. В простейшем случае такой запрос может быть реализован путем соединения пользовательского агента (UA) и базового сервера.
    Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартные формы посредников: прокси, туннель и внешний порт (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) представляет собой приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка-точка и не производит каких-либо видоизменений сообщений. Туннель используется тогда, когда нужно пройти через какую-то систему (например, Firewall) в условиях, когда эта система не понимает (не анализирует) содержимое сообщений.
    Код:
    Запрос -------------------------------------->
    
    UA -----v----- A -----v----- B -----v----- C -----v----- O
    
    <------------------------------------- отклик
    UA - агент пользователя
    На рисунке показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A, и переадресовывать запросы к другим серверам кроме C.
    Любой участник обмена, который не используется в качестве туннеля, может воспользоваться кэшем для запоминания запросов. Буфер может сократить длину цепочки в том случае, если у одного из участников процесса имеется в буфере отклик для конкретного запроса, что может, кроме прочего, заметно снизить требования к пропускной способности канала. Не все запросы могут записываться в кэш, некоторые из них могут содержать модификаторы работы с кэшем.
    В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии прокси-серверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, распространяющие фрагменты информации с CD-ROM, занесенной в кэши и т. д.. HTTP-системы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости.
    Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает использования HTTP поверх любого другого протокола в Интернет, или других сетей. HTTP предполагает надежное соединение; применим любой протокол, который может гарантировать корректную доставку сообщений.
    В HTTP/1.0, большинство приложений используют новое соединение для каждого обмена запрос/отклик. В HTTP/1.1, соединение может быть использовано для одного или более обменов запрос/отклик, хотя соединение может быть разорвано по самым разным причинам.
    Миниатюры
    Нажмите на изображение для увеличения
Название: image582.gif
Просмотров: 457
Размер:	18.3 Кб
ID:	2156   Нажмите на изображение для увеличения
Название: image583.gif
Просмотров: 314
Размер:	14.7 Кб
ID:	2157  
    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.157.30  
    Ответить с цитированием
    Старый 11.12.2007, 13:13   #2
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    По умолчанию

    Соглашения по нотации и общая грамматика
    1.1. Расширенные BNF
    Все механизмы, специфицированные в данном документе, описаны с использованием обычного текста и расширенных форм Бахуса-Наура BNF (Backus-Naur Form; см. RFC 822). Пользователи должны быть знакомы с этой нотацией для понимания данной спецификации. Расширение BNF включает в себя следующие конструкции:
    name = definition
    Имя правила не требует помещения в угловые скобки. Некоторые базовые правила записываются прописными буквами, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и пр.
    "literal"
    Двойные кавычки используются для выделения символьного текста.
    rule1 | rule2
    Элементы, разделенные вертикальной чертой, ("|") являются альтернативными, например, "yes | no" допускает yes или no (да или нет).
    (rule1 rule2)
    Элементы, помещенные в круглые скобки, рассматриваются как один элемент. Так, "(elem (foo | bar) elem)" допускают последовательности "elem foo elem" и "elem bar elem".
    *rule
    Символ "*", предшествующий элементу, указывает на повторение. Полная форма "*element" указывает как минимум на и как максимум повторений элемента. Значения по умолчанию равны 0 и бесконечности, так что "*( элемент)" позволяет любое число, включая ноль; "1*element" требует по меньшей мере один; а "1*2element" допускает один или два.
    [rule]
    В квадратные скобки заключаются опционные элементы; "[foo bar]" эквивалентно "*1(foo bar)".
    N rule
    Специальный повтор: "(элемент)" эквивалентно "*(элемент)"; то есть, точно (element). Таким образом, 2DIGIT является 2-значным числом, а 3ALPHA представляет собой строку из трех буквенных символов.
    #rule
    Конструкция "#" определена подобно "*", для описания списка элементов. Полная форма имеет вид "#element ", отмечая, по меньшей мере и по большей элементов, отделенных друг от друга одной или более запятыми (",") и опционно строчным пробелом (LWS - Linear White Space). Это делает обычную форму списков очень простой. Запись "( *LWS элемент *( *LWS "," *LWS элемент)) " может быть представлена как "1#element". Всюду, где используется эта конструкция, допускаются нулевые элементы, но они не учитываются при подсчете элементов. То есть, допускается запись "(элемент), (элемент) ", но число элементов при этом считается равным двум. Следовательно, там, где необходим хотя бы один элемент, должен присутствовать, по крайней мере, один ненулевой элемент. Значениями по умолчанию являются 0 и бесконечность, таким образом "#элемент" позволяет любое число, включая нуль; "1#элемент" требует, по меньшей мере один, а "1#2элемент" допускает один или два.
    ; комментарий
    Точка с запятой, смещенная вправо от линейки текста, открывает комментарий, который продолжается до конца строки. Это простой способ включения замечаний в текст спецификаций.
    implied *LWS
    Грамматика, описанная в данной спецификации, ориентирована на слова. Если не оговорено обратное, строчный пробел (LWS) может быть заключен между любыми двумя соседними словами (лексема или заключенная в кавычки строка), и между смежными лексемами (token) и разделителями (TSpecials) без изменения интерпретации поля. По крайней мере один разграничитель (TSpecials) должен присутствовать между любыми двумя лексемами, так как они иначе будут интерпретироваться как одна.
    1.2. Основные правила
    Следующие правила используются практически во всей спецификации для описания основных конструкций разбора (парсинга). OCTET = <любая 8-битовая последовательность данных>
    CHAR = <любой символ US-ASCII (октеты 0 - 127)>
    UPALPHA = <любая прописная буква US-ASCII "A".."Z">
    LOALPHA = < любая строчная буква US-ASCII "a".."z">
    ALPHA = UPALPHA | LOALPHA (строчная или прописная буква) DIGIT = <любая цифра US-ASCII "0".."9">
    CTL = <любой управляющий символ US-ASCII (октеты 0 - 31) и DEL (127)>
    CR =
    LF =
    SP =
    HT =
    <"> =

    HTTP/1.1 определяет последовательность CR LF, как маркер конца для всех протокольных элементов, за исключением тела элемента. Маркер конца строки в пределах тела объекта определен соответствующим типом среды. CRLF = CR LF
    HTTP/1.1 заголовки могут занимать несколько строк, если продолжение строки начинается с пробела или символа горизонтальной табуляции. Все строчные пробелы имеют ту же семантику, что и обычный пробел (SP). LWS = [CRLF] 1*( SP | HT )
    Правило TEXT используется только для содержимого описательных полей и значений, которые не предполагается передавать интерпретатору сообщений. Слова *TEXT могут содержать символы из символьного набора, не совпадающего с ISO 8859-1 [22], только когда они закодированы согласно правилам RFC-1522 [14]. TEXT = <любой OCTET за исключением CTL, но включая LWS>

    В некоторых протокольных элементах используются шестнадцатеричные цифровые символы. HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

    Многие значения полей заголовков HTTP/1.1 состоят из слов, разделенных LWS или специальными символами. Эти специальные символы должны представлять собой строки, заключенные в кавычки, чтобы использоваться в качестве значения параметра. Token = 1*<любой CHAR за исключением CTLs или tspecials>
    Tspecials = "(" | ")" | "<" | ">" | "@"

    | "," | ";" | ":" | "\" | <">

    | "/" | "[" | "]" | "?" | "="

    | "{" | "}" | SP | HT
    Комментарии могут быть включены в некоторые поля HTTP заголовков, при этом текст комментария заключается в скобки. Комментарии допустимы только для полей, содержащих "comment", как часть описания поля. В других полях скобки рассматриваются как элемент содержимого поля. Комментарий = "(" *( ctext | комментарий) ")"
    ctext = <любой TEXT, исключая "(" и ")">

    Строка текста воспринимается как одно слово, если она помещена в двойные кавычки. quoted-string = ( <"> *(qdtext) <"> )
    qdtext = <любой TEXT, исключая <">>


    Символ обратная косая черта ("\") может использоваться вместо кавычки внутри закавыченного текста или в структурах комментариев. quoted-pair = "\" CHAR
    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.157.30  
    Ответить с цитированием
    Старый 11.12.2007, 13:22   #3
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    Стрелка

    Продолжение статьи в архиве, страница в формате html
    Вложения
    Тип файла: rar http.rar (63.8 Кб, 196 просмотров)
    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.157.30  
    Ответить с цитированием
    Старый 11.12.2007, 13:26   #4
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    По умолчанию Другие сылки на эту тему:

    http://rpm.narod.ru/protocols/http.html
    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.157.30  
    Ответить с цитированием
    Старый 11.12.2007, 13:27   #5
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    Стрелка Компактный пост

    Обзор HTTP

    Hypertext Transfer Protocol (HTTP, протокол пересылки гипертекста) - это язык, которым клиенты и серверы World Wide Web пользуются для общения между собой. Он, по сути дела, является основой в Web.

    Хотя HTTP в большей степени относится к сфере программирования серверов и клиентов, знание этого протокола важно и для CGI-программирования. Кроме того, иногда HTTP фильтрует информацию и передает ее обратно пользователям - это происходит, например, когда в окне броузера отображаются коды ошибок сервера.


    Принципы работы HTTP

    Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из трех частей: строки запроса (ответа), раздела заголовка и тела. Клиент инициирует транзакцию следующим образом:

    1. Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем клиент посылает запрос документа, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например, в запросе

    GET /index.html HTTP/1.0

    используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html. Методы HTTP более подробно рассматриваются ниже.

    2. Клиент посылает информацию заголовка (необязательную), чтобы сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать. Вся информация заголовка указывается построчно, при этом в каждой строке приводится имя и значение. Например, приведенный ниже заголовок, посланный клиентом, содержит его имя и номер версии, а также информацию о некоторых предпочтительных для клиента типах документов:

    User-Agent: Mozilla/4.05 (WinNT; 1)
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

    Завершается заголовок пустой строкой.

    3. Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST. Клиенты (например, Netscape Navigator-Gold), также могут использовать их для помещения отредактированной страницы обратно на Web-сервер.

    Сервер отвечает на запрос клиента следующим образом:

    1. Первая часть ответа сервера - строка состояния, содержащая три поля: версию HTTP, код состояния и описание. Поле версии содержит номер версии HTTP, которой данный сервер пользуется для передачи ответа.

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

    НТТР/1.0 200 OK

    говорит о том, что сервер для ответа использует версию HTTP 1.0. Код состояния 200 означает, что запрос клиента был успешным и затребованные данные будут переданы после заголовков.

    2. После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка:

    Date: Fri, 10 Jan 1998 08:17:58 GMT
    Server: Apache/1.2.6
    Last-modified: Mon, 12 Jun 1997 21:53:08 GMT
    Content-type: text/html
    Content-length: 2482

    Завершает заголовок пустая строка.

    3. Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI-программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.

    В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы - изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.

    HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI-программы должны пользоваться скрытыми полями ввода или внешними средствами, например "ключиками" (cookies) Netscape.


    Запросы клиента

    Запросы клиента разбиваются на три раздела. Первая строка сообщения всегда содержит HTTP-команду, называемую методом, URI, который обозначает запрашиваемый клиентом файл или ресурс, и номер версии HTTP. Следующие строки запроса клиента содержат информацию заголовка. Информация заголовка содержит сведения о клиенте и информационном объекте, который он посылает серверу. Третья часть клиентского запроса представляет собой тело содержимого - собственно данные, посылаемые серверу.

    URI (Uniform Resource Identifier, универсальный идентификатор ресурса) - это общий термин для всех допустимых форматов схем адресации, поддерживаемых в World Wide Web. Сейчас общепринятой является схема адресации с использованием универсальных локаторов ресурсов (URL).

    Методы

    Метод - это HTTP-команда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Для HTTP определены три основных метода: GET, HEAD и POST. Определены и другие методы, но они не так широко поддерживаются серверами, как три перечисленных (хотя эти другие методы в будущем будут использоваться более часто). При задании имен методов учитывается регистр, поэтому GET и get различаются.

    Метод GET

    GET - это запрос информации, расположенной на сервере по указанному URL. GET - наиболее распространенный метод поиска с помощью броузеров документов для визуализации. Результат запроса GET может представлять собой, например, файл, доступный для сервера, результат выполнения программы или CGI-сценария, выходную информацию аппаратного устройства и т.д.

    Если клиент пользуется в своем запросе методом GET, сервер отвечает строкой состояния, заголовками и затребованными данными. Если сервер не может обработать запрос вследствие ошибки или отсутствия полномочий, он, как правило, посылает в информационном разделе ответа текстовое пояснение.

    Тело информационного содержимого запроса GET всегда пустое. GET в переводе на человеческий язык означает примерно следующее: "Дайте мне этот файл". Для идентификации указанных в запросе клиента файла или программы обычно используется полное имя этого объекта на сервере.

    Ниже приведен пример успешного запроса GET на получение файла. Клиент посылает запрос:

    GET /index.html HTTP/1.О
    Connection: Keep-Alive
    User-Agent: Mozilla/4.05 (WinNT; 1)
    Host: www.ora.com
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

    Сервер отвечает:

    HTTP/1.0 200 Document follows
    Date: Fri, 20 Jan 1998 08:17:58 GMT
    Server: Apache/1.2.6
    Last-modified: Mon, 20 Jun 1997 21:53:08 GMT
    Content-type: text/html
    Content-length: 2482

    (далее следует тело документа)

    Метод GET используется также для передачи входной информации в CGI-про- граммы посредством тегов форм. Поскольку тело запроса GET пусто, входные данные присоединяются к URL в строке GET запроса. Если в теге <form> задано значение атрибута method="GET", то пары ключ-значение, представляющие собой введенные данные из формы, присоединяются к URL после вопросительного знака. Пары отделяются друг от друга амперсандом (&). Например, по запросу

    GET /cgi-bin/birthday.pl?month=august&date=24 HTTP/1.О

    сервер передаст в CGI-программу birthday.pl значения month и date, указанные в форме, созданной на клиенте. Входные данные в конце URL кодируются в спецификации CGI. Чтобы специальные символы интерпретировались обычным образом, используются их шестнадцатиричные коды.

    Аналогичным образом в методе GET может передаваться информация о дополнительных путях. При этом дополнительный путь указывается после URL, т.е. /cgi-bin/display.pl/cgi/cgi_doc.txt. Сервер определяет, где заканчивается имя программы (display.pl). Все данные, которые следуют за именем программы, интерпретируются как дополнительный путь.

    Метод HEAD

    Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Информация заголовка запроса HEAD должна быть такой же, как в запросе GET.

    Этот метод используется, когда клиент хочет найти информацию о документе, не получая его. Для метода HEAD существует множество приложений. Например, клиент может затребовать следующую информацию:
    время изменения документа (эти данные полезны для запросов, связанных с кэш-памятью);
    размер документа (необходим для компоновки страницы, оценки времени передачи, определения необходимости запроса более компактной версии документа);
    тип документа (позволяет клиенту изучать документы только определенного типа);
    тип сервера (позволяет создавать специализированные запросы).

    Следует отметить, что большая часть информации заголовка, которую посылает сервер, не является обязательной и может предоставляться не всеми серверами. Рекомендуемый вариант для Web-клиентов - учитывать гибкость ответов сервера и предусматривать определенные меры по умолчанию, если сервер не передал необходимую информацию заголовка.

    Ниже приведен пример HTTP-транзакции с использованием запроса HEAD. Клиент посылает запрос:

    HEAD /index.html HTTP/1.0
    Connection: Close
    User-Agent: Mozilla/4.05 (WinNT; 1)
    Host: www.ora.com
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
    Сервер отвечает:

    HTTP/1.0 200 Document follows
    Date: Fri, 20 Jan 1998 08:17:58 GMT
    Server: Apache/1.2.6
    Last-modified: Mon, 17 Jun 1996 21:53:08 GMT
    Content-type: text/html
    Content-length: 2482

    (Тело содержимого в ответе на запрос HEAD не передается.)

    Метод POST

    Метод POST позволяет посылать на сервер данные в запросе клиента. Эти данные направляются в программу обработки данных, к которой сервер имеет доступ (например, в CGI-сценарий). Метод POST может использоваться во многих приложениях. Например, его можно применять для передачи входных данных для:
    сетевых служб (таких как телеконференции);
    программ с интерфейсом в виде командной строки;
    аннотирования документов на сервере;
    выполнения операций в базах данных.

    Данные, посылаемые на сервер, находятся в теле содержимого запроса клиента. По завершении обработки запроса POST и заголовков сервер передает тело содержимого в программу, заданную URL. В качестве схемы кодирования с методом POST используется URL-кодирование, которое позволяет преобразовывать данные форм в список переменных и значений для CGI-обработки.

    Ниже приведен небольшой пример запроса клиента с использованием метода POST. Клиент посылает на сервер данные о дне рождения, введенные в форму:

    POST /cgi-bin/birthday.pl HTTP/1.0
    User-Agent; Mozilla/4.05 (WinNT; 1)
    Accept: image/gif, iinage/x-xbj.tmap, image/jpeg, J.mage/pjpeg, */*
    Host: www.ora.com

    Content-type: application/x-www-form-ur.lencoded
    Content-Length: 20

    nionth=august&date=24


    Другие методы

    Приведенные ниже методы также определены, хотя и используются не столь часто:

    LINK Связывает информацию заголовка с документом на сервере.

    UNLINK Отменяет связь информации заголовка с документом на сервере.

    PUT Помещает тело содержимого запроса по указанному URI.

    DELETE Удаляет данные, находящиеся на сервере по заданному URI.

    OPTIONS Запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.

    TRACE Требует, чтобы тело содержимого запроса было возвращено без изменений. Используется для отладки.


    Ответы сервера

    Ответ сервера на запрос клиента состоит из трех частей. Первая строка - это строка ответа сервера, которая содержит номер версии HTTP, число, обозначающее состояние запроса, и краткое описание состояния. После строки ответа следует информация заголовка и тело содержимого, если таковое имеется.


    Коды ответов HTTP сервера

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


    Коды состояний обычно генерируются Web-серверами, но иногда это могут делать и CGI-сценарии, CGI-сценарии генерируют собственные заголовки вместо тех, которые должен выдавать сервер. Коды состояний группируются следующим образом:


    Диапазон кодов Значение ответа
    100-199 Информационный
    200-299 Запрос клиента успешен
    300-399 Запрос клиента переадресован, необходимы дальнейшие действия
    400-499 Запрос клиента является неполным
    500-599 Ошибки сервера

    В HTTP в каждом диапазоне определены лишь несколько кодов, хотя для сервера при необходимости могут определяться собственные коды. Клиент при получении кода, который он не может распознать, интерпретирует его в соответствии с диапазоном, к которому этот код принадлежит. Коды в диапазонах 100-199, 200-299 и 300-399 большинство Web-броузеров обрабатывают без извещения пользователя, а некоторые коды ошибок из диапазонов 400-499 и 500-599 отображаются для пользователя (например, 404 Not Found).


    Информационные ответы


    Ответы в диапазоне 100-199 - информационные; они показывают, что запрос клиента принят и обрабатывается.


    100 Continue
    Начальная часть запроса принята, и клиент может продолжать передачу запроса.

    101 Switching Protocols
    Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade.

    Успешные запросы клиента


    Ответы в диапазоне 200-299 означают, что запрос клиента обработан успешно.


    200 OK
    Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные.

    201 Created
    Этот код состояния используется в случае создания нового URI. Вместе с этим кодом результата сервер выдает заголовок Location (см. главу 19), который содержит информацию о том, куда были помещены новые данные.

    202 Accepted
    Запрос принят, но обрабатывается не сразу. В теле содержимого ответа сервера может быть дана дополнительная информация о данной транзакции. Гарантии того, что сервер в конечном итоге удовлетворит запрос, нет, даже несмотря на то, что на момент приема запрос выглядел допустимым.

    203 Non-Authoritative Information
    Информация в заголовке содержимого взята из локальной копии или у третьей стороны, а не с исходного сервера.

    204 No Content
    Ответ содержит код состояния и заголовок, но тело содержимого отсутствует. При получении этого ответа броузер не должен обновлять свой документ. Обработчик чувствительных областей изображений может возвращать этот код, когда пользователь щелкает на бесполезных или пустых участках изображения.

    205 Reset Content
    Броузер должен очистить форму, используемую в данной транзакции, для дополнительных входных данных. Полезен для CGI-приложений, требующих ввода данных.

    206 Partial Content
    Сервер возвращает лишь часть данных затребованного объема. Используется в ответе на запрос с указанием заголовка Range. Сервер должен указать диапазон, включенный в ответ, в заголовке Content-Range.


    Переадресация



    Код ответа в диапазоне 300-399 означает, что запрос не выполнен и клиенту нужно предпринять некоторые действия для удовлетворения запроса.

    300 Multiple Choices
    Затребованный URI обозначает более одного ресурса. Например, URI может обозначать документ, переведенный на несколько языков. В теле содержимого, возвращенном сервером, может находиться перечень более конкретных данных о том, как выбрать ресурс правильно.

    301 Moved Permanently
    Затребованный URI уже не используется сервером, и указанная в запросе операция не выполнена. Новое местонахождение затребованного документа указывается в заголовке Location. Во всех последующих запросах данного документа следует указывать новый URI.

    302 Moved Temporarily
    Затребованный URI перемешен, но лишь временно. Заголовок Location указывает на новое местонахождение. Сразу же после получения этого кода состояния клиент должен разрешить запрос при помощи нового URI, но во всех последующих запросах необходимо пользоваться старым URI.

    303 See Other
    Затребованный URI можно найти по другому URI (указанному в заголовке Location). Его следует выбрать методом GET по данному ресурсу.

    304 Not Modified
    Это код ответа на заголовок lf-Modified-Since, если URI не изменялся с указанной даты. Тело содержимого не посылается, и клиент должен использовать свою локальную копию.

    305 Use Proxy
    Доступ к затребованному URI должен осуществляться через proxy-сервер, указанный в заголовке Location.


    Неполные запросы клиента



    Коды ответов в диапазоне 400-499 означают, что запрос клиента неполный. Эти коды могут также означать, что от клиента требуется дополнительная информация.

    400 Bad Request
    Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.

    401 Unauthorized
    Этот код результата, передаваемый с заголовком WWW-Authenticate, показывает, что пославший запрос пользователь не имеет необходимых полномочий и что при повторении запроса с указанием данного URI пользователь должен такие полномочия предоставить.

    402 Payment Required
    Этот код в HTTP еще не реализован.

    403 Forbidden
    Запрос отклонен по той причине, что сервер не хочет (или не имеет возможности) ответить клиенту.

    404 Not Found
    Документ по указанному URI не существует.

    405 Method Not Allowed
    Этот код выдается с заголовком Allow и показывает, что метод, используемый клиентом, для данного URI не поддерживается.

    406 Not Acceptable
    Ресурс, указанный клиентом по данному URI, существует, но не в том формате, который нужен клиенту. Вместе с этим кодом сервер выдает заголовки Content-Language, Content-Encoding и Content-Type.

    407 Proxy Authentication Required
    Proxy-сервер должен санкционировать запрос перед тем, как пересылать его. Используется с заголовком Proxy-Authenticate.

    408 Request Time-out
    Этот код ответа означает, что клиент не передал полный запрос в течение некоторого установленного промежутка времени (который обычно задается в конфигурации сервера) и сервер разрывает сетевое соединение.

    409 Conflict
    Данный запрос конфликтует с другим запросом или с конфигурацией сервера. Информацию о конфликте следует возвратить в информационной части ответа.

    410 Gone
    Данный код показывает, что затребованный URI больше не существует и навсегда удален с сервера.

    411 Length Required
    Сервер не примет запрос без указанного в нем заголовка Content-Length.

    412 Precondition Failed
    Результат вычисления условия, заданного в запросе одним или несколькими заголовками if. . ., представляет собой "ложь".

    413 Request Entity Too Large
    Сервер не будет обрабатывать запрос, потому что его тело слишком велико.

    414 Request-URI Too Long
    Сервер не будет обрабатывать запрос, потому что его URI слишком длинный.

    415 Unsupported Media Type
    Сервер не будет обрабатывать запрос, потому что его тело имеет неподдерживаемый формат.


    Ошибки сервера



    Коды ответов в диапазоне 500-599 показывают, что сервер столкнулся с ошибкой и, вероятно, не сможет выполнить запрос клиента.

    500 Internal Server Error
    При обработке запроса на сервере один из его компонентов (например, CGI-программа) выдал аварийный отказ или столкнулся с ошибкой конфигурации.

    501 Not Implemented
    Клиент запросил выполнение действия, которое сервер выполнить не может.

    502 Bad Gateway
    Сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера).

    503 Service Unavailable
    Данный код означает, что данная служба временно недоступна, но в будущем доступ к ней будет восстановлен. Если сервер знает, когда это произойдет, может быть также выдан заголовок Retry-After.

    504 Gateway Time-out
    Этот ответ похож на 408 (Request Time-out) , за исключением того, что шлюз или уполномоченный сервер превысил лимит времени.

    505 HTTP Version not supported
    Сервер не поддерживает версию протокола HTTP, использованную в запросе.

    Этот текст был взят из книги Stephen Spainhour и Valerie Quercia "Webmaster in a nutshell".
    Перевод c английского С.М.Тимачева, под редакцией К.Ю.Королькова.
    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.157.30  
    Ответить с цитированием
    Старый 11.12.2007, 19:19   #6
    Powar
    Основатель Клуба
     
    Аватар для Powar
     
    Регистрация: 22.06.2006
    Адрес: Там где много пива
    Возраст: 32
    Сообщений: 3,767
    Powar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнутьPowar , такую репутацию нельзя пошатнуть
    Отправить сообщение для Powar с помощью ICQ
    По умолчанию

    Powar вне форума IP: 77.94.193.125  
    Ответить с цитированием
    Старый 11.12.2007, 20:53   #7
    Programmist
    Основатель Клуба
     
    Аватар для Programmist
     
    Регистрация: 23.06.2006
    Адрес: Еноты, еноты, кругом одни еноты...
    Возраст: 37
    Сообщений: 3,367
    Programmist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнутьProgrammist , такую репутацию нельзя пошатнуть
    По умолчанию

    __________________
    Тьмак вас всех.......
    FV4H6WPRMLQBEIRBJQM432RPK66KM6QF35NFSQA
    Programmist вне форума IP: 88.147.217.178  
    Ответить с цитированием
    Ответ
    Загрузка...


    Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
     
    Опции темы
    Опции просмотра

    Ваши права в разделе
    Вы не можете создавать новые темы
    Вы не можете отвечать в темах
    Вы не можете прикреплять вложения
    Вы не можете редактировать свои сообщения

    BB коды Вкл.
    Смайлы Вкл.
    [IMG] код Вкл.
    HTML код Выкл.

    Быстрый переход


    Часовой пояс GMT +3, время: 20:12.


    Яндекс цитирования

    Powered by vBulletin® Version 3.8.0 Beta 3
    Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
    The design belongs to EX_isTentiA