Универсальный идентификатор ресурсов (URI), его назначение и составные части. Для доступа к любым сетевым ресурсам необходимо знать где они размещены и как к ним можно обратиться. Во Всемирной паутине используется стандартизованная схема адресации и идентификации, учитывающую опыт адресации и идентификации e-mail, Gopher, WAIS, telnet, ftp и т.п. - URL, Uniform Resource Locator. URI (Uniform Resource Identifier, Универсальный идентификатор ресурса) (RFC 2396, August 1998) - компактная строка символов для идентификации абстрактного или физического ресурса. Под ресурсом понимается любой объект, принадлежащий некоторому пространству. Включает и переопределяет определенные ранее URL (RFC 1738/RFC 1808) и URN (RFC 2141, RFC 2611). URI предназначен для уникальной идентификации любого ресурса. Некоторые подмножества URI: URN (Uniform Resource Name, Универсальное имя ресурса) - частная URI-схема "urn:" с подмножеством "пространства имен", который должен быть уникальным и неизменным даже в том случае, когда ресурс уже не существует или недоступен. Предполагается что, например браузер, знает, где искать этот ресурс. Синтаксис: urn:namespace: data1.data2,more-data, где namespace (пространство имен) определяет, каким образом используются данные, указанные после второго ":". Пример URN: urn:ISBN: 0-395-36341-6 ISBN - тематический классификатор для издательств 0-395-36341-6 - конкретный номер тематики книги или журнала При получении URN клиентская программа обращается к ISBN (каталогу "тематический классификатор для издательств" в Интернете). И получает расшифровку номера тематики "0-395-36341-6" (например: "квантовая химия"). URN массово используется в P2P сетях (подобных edonkey). Пример URN указывающего на образ диска Adobe Photoshop v8.0 в сети edonkey: urn:ed2k://|file|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/ где: ed2k - указывает на сеть file - файл Adobe Photoshop v8.0.iso - название файла 940769280 - размер в байтах b34c101c90b6dedb4071094cb1b9f2d3 - идентификатор файла (вычисляется с помощью хеш-функции) Универсальный указатель ресурса URL: URL (Uniform Resource Locator, RFC 1738) - унифицированный локатор (указатель) ресурсов, стандартизированный способ записи адреса ресурса в WWW и сети Интернет. Адрес URL имеет гибкую и расширяемую структуру для максимально естественного указания местонахождения ресурсов в сети, который идентифицирует ресурс по способу доступа к нему (например, его "местонахождению в сети") вместо того, чтобы идентифицировать его по названию или другим атрибутам этого ресурса. Примеры URL: http://www.ipm.kstu.ru/index.php ftp://www.ipm.kstu.ru/ Для представления адреса используется ограниченный набор символов ASCII. Общий вид адреса можно представить так: <схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу> Где: схема обращения к ресурсу: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais и т.п. логин:пароль- имя пользователя и его пароль, используемые для доступа к ресурсу хост-доменное имя хоста или его IP-адрес. Порт- порт хоста для подключения полный-путь-к-ресурсу - уточняющая информация о месте нахождения ресурса (зависит от протокола). Примеры URL: http://example.com #запрос стартовой страницы по умолчанию http://www.example.com/site/map.html #запрос заданной страницы в указанном каталоге http://example.com:81/script.php #подключение на нестандартный порт http://example.org/script.php?key=value #запрос с передачей параметров скрипту ftp://user:pass@ftp.example.org #подключение к ftp-серверу с авторизацией http://192.168.0.1/example/www #подключение по сетевому адресу file:///srv/www/htdocs/index.html #открытие локального файла gopher://example.com/1 #подключение к серверу gopher URL - Uniform Resource Locators явно описывает, как добраться до объекта. Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания- [a-z0-9+.-]. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нужные нам символы должны быть перекодированы особым образом. В русскоязычной Википедии ежедневно приходится видеть примеры кодирования URL, поскольку русский язык использует символы кириллицы. Например, строка вида: http://ru.wikipedia.org/wiki/Микрокредит кодируется в URL как: http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82 Такое преобразование происходит в два этапа: сначала каждый символ кириллицы кодируется в Юникоде (UTF-8) в последовательность из двух байтов, а затем каждый байт этой последовательности записывается в шестнадцатеричном представлении: М → D0 и 9C → %D0%9C и → D0 и B8 → %D0%B8 к → D0 и BA → %D0%BA р → D1 и 80 → %D1%80, и т. д. Перед каждым таким шестнадцатеричным кодом байта, согласно спецификации URL, ставится знак процента (%) — отсюда даже возник английский термин «percent-encoding», обозначающий способ кодирования символов в URL и URI. Поскольку такому преобразованию подвергаются буквы всех алфавитов, кроме базовой латиницы, то URL со словами на подавляющем большинстве языков (кроме английского, итальянского, латинского) может стать нечитаемым для человека. Это всё входит в противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (International Resource Identifier) — международных идентификаторов ресурсов, в которых можно было бы без проблем использовать символы Юникода, и которые поэтому не ущемляли бы права других языков. Другие схемы URL Схема HTTP. В схеме указывается ее идентификатор, адрес машины, TCP-порт, путь в директории сервера, переменные и их значения, метка. Синтаксис: http://[<user>[:<password]>@]<host>[:<port>][/[<url-path>][?<query>]] http - название схемы user - имя пользователя password - пароль пользователя host - имя хоста port - номер порта url-path - путь к файлу и сам файл query (<имя-поля>=<значение>{&<имя-поля>=<значение>) - строка запроса Определен в RFC 2068. По умолчанию, port=80. Примеры: http://ipm.kstu.ru/internet/index.php Это наиболее распространенный вид URI, применяемый в документах WWW. Вслед за именем схемы (http) следует путь, состоящий из доменного адреса машины и полного адреса HTML-документа в дереве сервера HTTP. В качестве адреса машины допустимо использование и IP-адреса: http://195.208.44.20/internet/index.php Если сервер протокола HTTP запущен на другой, отличный от 80 порт TCP, то это отражается в адресе: http://195.208.44.20:8080/internet/index.php При указании адреса ресурса возможна ссылка на метку внутри файла HTML. Для этого вслед за именем документа может быть указана метка внутри документа: http://195.208.44.20/internet/index.php#metka1 Символ "#" отделяет имя документа от имени метки. Переменные и их значения передаются следующим образом: http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2 Значения "var1" и "var2" - это имена переменных, а "value1" и "value2" - их значения. Схема FTP Данная схема позволяет адресовать файловые архивы FTP. Синтаксис: ftp://[<user>[:<password]>@]<host>[:<port>][/<url-path>] ftp - название схемы user - имя пользователя password - пароль пользователя host - имя хоста port - номер порта url-path - путь к файлу и сам файл Определен в RFC 1738. По умолчанию, port=21, user=anonymous, password=email-адрес, если имя указано, а пароль нет, то он запрашивается в диалоге. <url-path> имеет вид: <cwd1>/<cwd2>/.../<cwdN>/<name>[;type=<typecode>], где <typecode>: <url-path> Примеры: ftp://ipm.kstu.ru/students/name/ Чтобы указать имя пользователя и его пароль, надо записать так: ftp://name:password@ftp://ipm.kstu.ru/students/name/ В данном случае эти параметры отделены от адреса машины символом "@", а друг от друга двоеточием. Схема MAILTO Данная схема предназначена для отправки почты. Синтаксис: mailto:[<e-mail-1>{,<e-mail-2>,...}][?<query>] mailto - название схемы e-mail-1 (<user>@<host>)- первый адрес электронной почты user - имя пользователя host - имя хоста e-mail-2 - второй адрес электронной почты query (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - строка запроса Примеры: mailto:name@ipm.kstu.ru В этой схеме передаются поля и их значения: Пример: mailto:name@ipm.kstu.ru?subject=Тема_письма&body=Текст_который _будет_вставлен_в_письмо Адрес получателя можно также записывать в виде значения поля to: mailto:?to=name@ipm.kstu.ru?subject=Тема_письма&body=Текст_который _будет_вставлен_в_письмо Что такое HTTP? Первый документ (но не стандарт) - RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996) Последняя версия - RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee June 1999) Hypertext Transfer Protocol - протокол передачи гипертекста, протокол высокого уровня (а именно, уровня приложений). Используется службой WWW для передачи Web-страниц. HTTP (HyperText Transfer Protocol, RFC 2616, текущая версия HTTP/1.1) - протокол передачи гипертекста. Этот протокол изначально был предназначен для обмена гипертекстовыми документами, сейчас его возможности существенно расширены (в частности, добавлены функции поддержки потокового вещания). HTTP - типичный клиент-серверный протокол, обмен сообщениями идёт по схеме «запрос-ответ» в виде ASCII-команд. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым. HTTP - протокол прикладного уровня, но используется также в качестве «транспорта» для других прикладных протоколов, таких как SOAP, XML-RPC, WebDAV. Протокол HTTP определяет запрос-ответный способ взаимодействия между программой-клиентом и программой-сервером в рамках технологии World Wide Web. Для загрузки web-страницы в клиентский броузер тот посылает установленной на серверном компьютере специальной программе, называемой http-сервером, соответствующий запрос и обрабатывает полученные от него данные. В данном случае функции броузера состоят в том, чтобы запросить у сервера определенную страницу, получить ее и отобразить на экране пользователя. Сервер же принимает запрос, ищет запрошенный документ и выдает клиенту либо содержимое найденного файла, либо сообщение об ошибке, если такой файл не был найден или доступ к нему почему-либо запрещен. Важным моментом для понимания данного процесса является то, что http-сервер не анализирует содержимое передаваемого документа. Грубо говоря, http-серверу все равно, что находится внутри запрошенного файла, он только передает его броузеру, а всю работу по структурированию и отображению полученной информации тот уже берет на себя Поиск запрашиваемой страницы осуществляется в определенной директории, которая отведена на серверном компьютере под данный сайт — ссылка на эту директорию присутствует во введенном пользователем адресе. В случае, когда обращение осуществляется не к конкретному документу, а к сайту в целом, http-сервер автоматически подставляет вместо названия передаваемого файла так называемую «стартовую страницу», которая носит имя index.htm или index.html (в некоторых случаях — default.htm или default.html). Этот документ обязательно должен располагаться в корневом каталоге, отведенном для размещения вашего сайта, либо, если это оговорено особо, в директории с названием WWW. Все остальные файлы можно размещать либо в этом же каталоге, либо во вложенных директориях, что иногда бывает удобным, особенно в случае, когда сайт содержит несколько тематических разделов или рубрик. Помимо созданных вами вложенных папок, в которые вы вольны помещать практически любое необходимое вам содержимое, серверная директория содержит обычно еще несколько каталогов, которые следует упомянуть отдельно. Во-первых, это папка CGI-BIN, где размещаются CGI-скрипты и другие запускаемые с вашего сайта интерактивные приложения, а также несколько служебных директорий, необходимых для нормальной работы сервера. На начальном этапе на них просто не следует обращать внимания. Иногда в том же каталоге, где хранится index.html, присутствует ряд дополнительных файлов: not_found.html — документ, который отображается в случае, если http-сервер не смог найти запрашиваемый пользователем файл, forbidden.html — отображается в качестве сообщения об ошибке, если доступ к запрашиваемому документу запрещен, и, наконец, robots.txt — файл, в котором специальным образом описываются правила индексации вашего сайта поисковыми машинами. В большинстве случаев, а особенно при публикации домашней странички на серверах, предоставляющих бесплатный хостинг, к служебным директориям и папке CGI-BIN доступ пользователям закрыт, изменение содержимого файлов not_found и forbidden.html также невозможно. Это следует учитывать, если вы планируете включить в свой ресурс какое-либо интерактивное содержимое, требующее как минимум возможности помещать файлы в одну из служебных папок. В некоторых случаях вам может быть запрещено создавать на сервере вложенные каталоги, тогда пользователю придется довольствоваться исключительно одной директорией, отведенной для ваших нужд. Из всего сказанного становится ясно, что броузер клиента может только получать и обрабатывать информацию с сервера, а размещать и изменять ее — лишь в том случае, если загрузка файлов на сервер реализована на основе протокола HTTP с помощью специальных CGI-скриптов, включенных в серверный web-интерфейс. Во всех остальных случаях приходится пользоваться так называемым ftp-сервером, на который посредством специального программного обеспечения можно передать необходимые файлы, автоматически загружая их в отведенную для вашего сайта директорию. В обоих случаях вам потребуется знать свое регистрационное имя и пароль для доступа к системе. Следует также помнить, что большинство серверных программ (в частности, Apache для UNIX-совместимых платформ) различают строчный и заглавный регистр символов, поэтому все имена файлов и их расширения во избежание ошибок следует писать строчными буквами, причем обязательно латиницей. Последнее связано с различиями в обработке кодировок русского языка, характерной для тех или иных серверов. Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту. Взаимодействие между клиентом и сервером Web осуществляется путём обмена сообщениями. Сообщения HTTP делятся на запросы клиента серверу и ответы сервера клиенту. Сообщения запроса и ответа имеют общий формат. Оба типа сообщений выглядят следующим образом: сначала идет начальная строка (start-line), затем, возможно, одно или несколько полей заголовка, называемых, также, просто заголовками, затем пустая строка (то есть строка, состоящая из символов CR и LF), указывающая конец полей заголовка, а затем, возможно, тело сообщения: начальная строка поле заголовка 1 поле заголовка 2 . . . поле заголовка N CR LF тело сообщения Заголовки протокола HTTP Формат начальной строки клиента и сервера различаются и будут рассмотрены ниже. Заголовки бывают четырёх видов: - общие заголовки (general-headers), которые могут присутствовать как в запросе, так и в ответе; - заголовки запросов (request-headers), которые могут присутствовать только в запросе; - заголовки ответов (response-headers), которые могут присутствовать только в ответе; - заголовки объекта (entity-headers), которые относятся к телу сообщения и описывают его содержимое. Каждый заголовок состоит из названия, символа двоеточия ":" и значения. Наиболее важные заголовки приведены в таблице 1. Таблица 1 Заголовки протокола HTTP Заголовок | Назначение | Заголовки объекта | Allow | Перечисляет поддерживаемые сервером методы | Content-Encoding | Способ, которым закодировано тело сообщения, например, с целью уменьшения размера | Content-Length | Длина сообщения в байтах | Content-Type | Содержит обозначение типа содержимого ответа в MIME. В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Некоторые типы содержимого: text/html - текст в формате HTML (веб-страница); text/plain - простой текст (аналогичен "блокнотовскому"); image/jpeg - картинка в формате JPEG; image/gif - то же, в формате GIF; Также может передавать кодировку для текстовых данных. Например: charset=windows-1251 charset=koi8-rus Content-Length - длина содержимого ответа в байтах (размер файла). Last-Modified - дата и время последнего изменения документа. | ETag | Уникальный тэг ресурса на сервере, позволяющий сравнивать ресурсы | Expires | Дата и время, когда ресурс на сервере будет изменён, и его нужно получать заново | Last-Modified | Дата и время последней модификации содержимого | Заголовки ответа | Age | Число секунд, через которое нужно повторить запрос для получения нового содержимого | Location | URI ресурса, к которому нужно обратиться для получения содержимого | Retry-After | Дата и время или число секунд, через которое нужно повторить запрос, чтобы получить успешный ответ | Server | Название программного обеспечения сервера, приславшего ответ | Заголовки запроса | Accept | Список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например:Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах. Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера. | Accept-Charset | Кодировки символов, в которых клиент может принимать текстовое содержимое | Accept-Encoding | Способ, которым сервер может закодировать сообщение | Host | Хост и номер порта, с которого запрашивается документ | If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since | Заголовки запроса для условного обращения к ресурсу | Range | Запрос части документа | User-Agent | Название программного обеспечения клиента- значением является "кодовое обозначение" браузера, например: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt) | Общие заголовки | Connection | Connection (соединение) - может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close. close ("закрыть") - соединение закрывается после ответа на данный запрос. | Date | Дата и время формирования сообщения | Pragma | Специальные, зависящие от реализации команды, касающиеся передаваемого содержимого | Transfer-Encoding | Способ кодирования сообщения при передачи | В некоторых заголовках значением является дата и время. Они должны быть представлены в формате, описанном в RFC 1123, например: Sun, 06 Nov 1994 08:49:37 GMT В теле сообщения содержится собственно передаваемая информация – полезная нагрузка сообщения. Тело сообщения представляет собой последовательность октетов (байтов). Тело сообщения может быть закодировано, при этом способ кодирования указывается в заголовке объекта Content-Encoding. Сообщение запроса от клиента к серверу состоит из строки запроса (request-line), заголовков (общих, запросов, объекта) и, возможно, тела сообщения. Строка запроса начинается с метода, затем следует идентификатор запрашиваемого ресурса, версия протокола и завершающие символы конца строки: <Метод> <Идентификатор> <Версия HTTP> Метод указывает метод, который нужно применить к запрашиваемому ресурсу. Например, метод GET говорит о том, что клиент хочет получить содержимое ресурса. Идентификатор определяет запрашиваемый ресурс. Версия HTTP обозначается строкой следующего вида: HTTP/<версия>.<подверсия> Методы протокола HTTP Рассмотрим основные методы протокола HTTP. OPTIONS Метод OPTIONS выполняет запрос информации об опциях соединения (например, методах, типах документов, кодировках), которые поддерживает сервер для запрашиваемого ресурса. Этот метод позволяет клиенту определять опции и/или требования, связанные с ресурсом, или возможности сервера, не производя никаких действий над ресурсом и не инициируя его загрузку. Если ответ сервера – это не сообщение об ошибке, то заголовки объекта содержат информацию, которую можно рассматривать как опции соединения. Например, в заголовке Allow перечислены все методы, поддерживаемые сервером для данного ресурса. Если идентификатор запрашиваемого ресурса – звёздочка ("*"), то запрос OPTIONS предназначен для обращения к серверу в целом. Если идентификатор запрашиваемого ресурса – не звездочка, то запрос OPTIONS применяется к опциям, которые доступны при соединении с указанным ресурсом. GET Метод GET позволяет получать любую информацию, связанную с запрашиваемым ресурсом. В большинстве случаев, если идентификатор запрашиваемого ресурса указывает на документ (например, текстовый документ, графическое изображение, видеоролик), то сервер возвращает содержимое этого документа (содержимое файла). Если запрашиваемый ресурс является приложением (программой), формирующим данные, то в теле сообщения ответа возвращаются сформированные данные, а не двоичный образ выполняемого файла. Это используется, например, при создании приложений CGI. Если идентификатор запрашиваемого ресурса указывает на директорию (каталог, папку), то, в зависимости от настроек сервера, может быть возвращено либо содержимое директории (список файлов), либо содержимое одного из файлов, находящегося в этой директории (как правило, index.html или Default.htm). В последнем случае имя папки может указываться как с символом "/" на конце, так без него. При отсутствии на конце идентификатора данного символа сервер выдаёт один из ответов с перенаправлением (с кодами статуса 301 или 302). Различается "условный GET" ("conditional GET"), при котором сообщение запроса включает заголовки запроса If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Условный метод GET запрашивает передачу объекта, только если он удовлетворяет условиям, описанным в приведённых заголовках. Условный метод GET предназначен для уменьшения ненужной загрузки сети, поскольку позволяет не загружать вторично уже сохранённые клиентом данные. Различается также "частичный GET" ("partial GET"), при котором сообщение запроса включает заголовок запроса Range. Частичный GET запрашивает передачу только части объекта. Частичный метод GET предназначен для уменьшения ненужной загрузки сети, за счёт запроса только части объекта, когда другая часть уже загружена клиентом. Значением заголовка Range является диапазон байтов, которые необходимо получить. Байты нумеруются с 0. Начальный и конечный байты диапазона разделяются символом "–". Если нужно получить несколько диапазонов, то они перечисляются через запятую. HEAD Метод HEAD идентичен GET, за исключением того, что сервер не возвращает в ответе тело сообщения. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD идентична информации, представляемой в ответ на запрос GET. Этот метод может использоваться для получения информации об объекте запроса без непосредственной пересылки тела объекта. Метод HEAD часто используется для тестирования гипертекстовых связей. POST Метод POST используется для запроса, при котором адресуемый сервер принимает данные, включённый в тело сообщения (объект) запроса, и отправляет их на обработку приложению, указанному как запрашиваемый ресурс. POST разработан для того, чтобы общим методом реализовать следующие функции: - аннотация существующих ресурсов; - регистрация сообщения на электронной доске объявлений (BBS), в конференциях новостей (newsgroups), списках рассылки (mailing lists) или подобной группе статей; - передача блока данных, например результат ввода в форме, процессу обработки; - выполнение запросов к базам данных (БД); - загрузка файлов на сервер. Фактически функция, выполняемая методом POST, определяется приложением, на которое указывает идентификатор запрашиваемого ресурса. Наряду с методом GET, метод POST используется при создании приложений CGI. Браузер может формировать запросы с методом POST при отправке форм. Для этого элемент FORM документа HTML, содержащего форму, должен иметь атрибут METHOD со значением POST. Действие, выполняемое методом POST, может выполнить действие на сервере и не передать никакого содержимого в качестве результата работы. В этом случае, в зависимости от того, включает ответ тело сообщения, описывающее результат, или нет, код состояния в ответе может быть как 200 (OK), так и 204 (Нет содержимого, No Content). Если ресурс на сервере был создан, ответ содержит код состояния 201 (Создан, Created) и включает заголовок ответа Location. PUT Тело сообщения, которое передаётся в запросе с методом PUT, сохраняется на сервере, причём идентификатор запрашиваемого ресурса будет идентификатором сохранённого документа. Если идентификатор запрашиваемого ресурса указывает на уже существующий ресурс, то включённый в тело сообщения объект рассматривается как модифицированная версия ресурса, находящегося на сервере. Если новый ресурс создан, то сервер сообщает пользовательскому агенту об этом посредством ответа с кодом состояния 201 (Создан, Created). Фундаментальное различие между методами POST и PUT заключается в различном значении идентификатора запрашиваемого ресурса. URI в запросе POST идентифицирует ресурс, который обрабатывает включенный в тело сообщения объект. Этим ресурсом может быть приложение, принимающее данные. Напротив, URI в запросе PUT идентифицирует объект, включенный в запрос в виде тела сообщения, то есть пользовательский агент назначает данный URI включенному ресурсу. DELETE Метод DELETE запрашивает сервер об удалении ресурса, имеющего запрашиваемый идентификатор. Запрос с данным методом может быть отвергнут сервером, если у пользователя нет прав на удаление запрашиваемого ресурса. TRACE Метод TRACE используется для возврата переданного запроса на уровне протокола HTTP. Получатель запроса (сервер Web) отправляет полученное сообщение обратно клиенту как тело объекта ответа с кодом состояния 200 (OK). Запрос TRACE не должен содержать тела сообщения. TRACE позволяет клиенту видеть, что получает на другом конце сервер и использовать эти данные для тестирования или диагностики. Если запрос успешно выполнен, то ответ содержит всё сообщение запроса в теле сообщения ответа, а заголовок объекта Content-Type имеет значение "message/http". Коды ответов После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP ответа. Первая строка ответа – это строка состояния (Status-Line). Она состоит из версии протокола, числового кода состояния, поясняющей фразы, разделенных пробелами и завершающих символов конца строки: <Версия HTTP> <Код состояния> <Поясняющая фраза> Версия протокола имеет то же значение, что и в запросе. Элемент код состояния (Status-Code) - это целочисленный трехразрядный (трёхзначный) код результата понимания и удовлетворения запроса. Поясняющая фраза (Reason-Phrase) представляет собой короткое текстовое описание кода состояния. Код состояния предназначен для обработки программным обеспечением, а поясняющая фраза предназначена для пользователей. Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры: - 1xx: Информационные коды - запрос получен, продолжается обработка. - 2xx: Успешные коды - действие было успешно получено, понято и обработано. - 3xx: Коды перенаправления - для выполнения запроса должны быть предприняты дальнейшие действия. - 4xx: Коды ошибок клиента - запрос имеет ошибку синтаксиса или не может быть выполнен. - 5xx: Коды ошибок сервера - сервер не в состоянии выполнить допустимый запрос. Поясняющие фразы (Reason-Phrase) для каждого кода состояния перечислены в RFC 2068 и являются рекомендуемыми, но могут быть заменены на эквивалентные без воздействия на протокол. Например, в локализованных русскоязычных версиях HTTP серверов эти фразы заменены русскими. В таблице 2 приведены коды ответов сервера HTTP. Таблица 2 Коды ответов сервера HTTP Код | Поясняющая фраза согласно RFC 2068 | Эквивалентная поясняющая фраза на русском языке | 1xx: Информационные коды | | Continue | Продолжать | 2xx: Успешные коды | | OK | OK | | Created | Создан | | No Content | Нет содержимого | | Reset Content | Сбросить содержимое | | Partial Content | Частичное содержимое | 3xx: Коды перенаправления | | Moved Temporarily | Временно перемещен | | Not Modified | Не модифицирован | 4xx: Коды ошибок клиента | | Bad Request | Испорченный Запрос | | Unauthorized | Несанкционированно | | Not Found | Не найден | | Method Not Allowed | Метод не дозволен | | Request Timeout | Истекло время ожидания запроса | | Conflict | Конфликт | | Length Required | Требуется длина | | Request Entity Too Large | Объект запроса слишком большой | 5xx: Коды ошибок сервера | | Internal Server Error | Внутренняя ошибка сервера | | Not Implemented | Не реализовано | | Service Unavailable | Сервис недоступен | | HTTP Version Not Supported | Не поддерживаемая версия HTTP | За строкой состояния следуют заголовки (общие, ответа и объекта) и, возможно, тело сообщения. Одной из важнейших функций сервера Web является предоставление доступа к части локальной файловой системы. Для этого в настройках сервера указывается некоторая директория, которая является корневой для данного сервера. Чтобы опубликовать документ, то есть, сделать его доступным пользователям, "посетившим" данный сервер (осуществившим с ним соединение по протоколу HTTP), нужно скопировать этот документ в корневую директорию Web-сервера или в одну из её поддиректорий. При соединении по протоколу HTTP на сервере создаётся процесс с правами пользователя, как правило, не существующего реально, а специально созданного для просмотра ресурсов сервера. Настраивая права и разрешения данного пользователя можно управлять доступом к ресурсам Web. Рассмотрим простейший пример HTTP - запроса. Если в адресном окне браузера мы наберем адрес http://yandex.ru, то браузер определит IP адрес сервера yandex.ru и пошлет ему на 80-й порт такой HTTP запрос: GET http://yandex.ru/ HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: ru Cookie: yandexuid=2464977781018373381 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Host: yandex.ru Referer: narod.ru Proxy-Connection: Keep-Alive Запрос передается в незашифрованном текстовом виде. Самая главная часть запроса расположена в первой строке: Это тип запроса (GET), URL адрес запрашиваемого документа(http://yandex.ru) и версия HTTP протокола (HTTP/1.0). Далее перечисляются параметры запроса. Каждая строка соответствует одному параметру. В начале строки идет имя параметра, затем двоеточие и значение параметра. Accept - тип данных, которые может принять браузер (в кодировке MIME). Accept-Language - предпочтительный язык, на котором браузер хочет принять данные. User-Agent - тип программы, которая отослала запрос. Host – DNS (или IP) имя хоста, которому адресован запрос. Cookie - кукисы (данные, которые были сохранены сервером на локальном диске клиента, при посещении данного хоста прошлый раз). Referer - хост, со страницы которого мы отсылаем запрос. Так, например, если мы находимся на странице http://narod.ru, и нажимаем там ссылкуhttp://yandex.ru, то запрос будут отправлен хосту yandex.ru, а поле запроса referer будет содержать имя хоста narod.ru. Набор параметров запроса не фиксирован. Помимо приведенных, могут присутствовать и другие параметры. Наиболее интересны такие параметры, как referer и cookie. Эти параметры используются, в основном, для идентификации пользователя сервером. Запрос GET может содержать данные, передаваемые клиентом серверу. Они передаются непосредственно через URL адрес по CGI протоколу. Данные отделены от URL знаком “?” и соединяются знаком “&”: GET <URL>?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&… Такой тип передачи данных серверу удобен, однако имеет ограничения на объем. Слишком большие массивы данных передавать через URL нельзя. Для таких целей существует другой тип зпросов: запрос POST. Запрос POST очень похож на GET, с той лишь разницей, что данные в запросе POST передаются отдельно от самого заголовка запроса: Тело запроса должно отделяться от заголовка пустой строкой. Если сервер встречает пустую строку в POST запросе, то все что идет далее он считает телом запроса (передаваемыми данными). Отметим следующее: формат даных в теле POST запроса произволен. Несмотря на то, что чаще всего применяется CGI формат, он не обязателен. Кроме того, POST запрос не требует наличия тела запроса, и может передавать данные также и через URL. Помимо CGI формата, иногда для передачи больших объемов информации (например файлов) применяют т.н. multipart формат (формат передаваемых данных определяется параметром Content-Type): Современные браузеры содержат инструменты для веб-разработчиков, позволяющие получить некоторую информацию об отправляемых запросах post. Если вам требуется посмотреть заголовки всего пары запросов, их использование будет проще и быстрее других способов. Если вы используете Firefox, вы можете воспользоваться его веб-консолью. Она отображает заголовки запросов и содержимое передаваемых файлов cookies. Для ее запуска раскройте меню браузера, щелкните по пункту «Веб-разработка» и выберите «Веб-консоль». В появившейся панели активируйте кнопку «Сеть». Введите в поле фильтра название метода – post. В зависимости от ваших целей, нажмите на кнопку формы отправляющей нужный запрос или обновите страницу. В консоли отобразится отправленный запрос. Кликните по нему мышкой, чтобы посмотреть подробнее. Браузер Google Chrome имеет мощные инструменты отладки. Чтобы ими воспользоваться, кликните по иконке с изображением гаечного ключа, а затем раскройте пункт «Настройка и управление Google Chrome». Выберите пункт «Инструменты» и запустите «Инструменты разработчиков». В панели инструментов выберите вкладку Network и отправьте запрос. Найдите нужный запрос в списке и кликните по нему, чтобы изучить подробности. В браузере Opera имеются встроенные инструменты для разработчиков Opera Dragonfly. Для их запуска кликните правой клавишей мышки по нужной странице и выберите пункт контекстного меню «Проинспектировать элемент». Перейдите на вкладку «Сеть» инструментов для разработчиков и отправьте нужный запрос. Найдите его в списке и раскройте, чтобы изучить заголовки и ответы сервера. Internet Explorer 9 содержит комплект под названием «Средства разработчика F12», предоставляющие подробную информацию по выполненным запросам. Они запускаются нажатием кнопки F12 или с помощью меню «Сервис», содержащее одноименный пункт. Чтобы посмотреть запрос, перейдите на вкладку «Сеть». Найдите заданный запрос в сводке и с помощью двойного клика раскройте подробную информацию. Браузеры Chrome и Internet Explorer 9 содержат встроенные инструменты, позволяющие изучить отправленный запрос post во всех деталях. Для получения полной информации используйте их или Firefox с установленным плагином Firebug. Он очень удобен для частого изучения запросов, например, при отладке сайтов. Если вы хотите посмотреть запрос, отправленный не браузером, а какой либо другой программой, воспользуйтесь HTTP-отладчиком Fiddler. Он работает как прокси-сервер и перехватывает запросы любой программы, а также предоставляет очень подробную информацию по их заголовкам и содержимому. |