Получение информации о сервере

Два новых метода получения информации о сервере были введены в НТТР/1.1. Это методы OPTIONS и TRACE. Мы рассмотрим их здесь подробно.

МЕТОД OPTIONS

В НТТР/1.0 у клиента не было средств узнать о возможностях Web-cepBepa. Метод OPTIONS был введеп в НТТР/1.1, чтобы удовлетворить эту потребность.

Рассмотрим следующие ситуации:

• Возможно, что клиенту пужпо узнать, реализован ли в Web-сервере метод, не являющийся обязательным для реализации (любой метод, не относящийся к уровню требований MUST). Предположим, что клиентом был послап запрос PUT большого объема, который был отклонен сервером из-за невозможности

обработать. Передача отклоняемых сервером запросов большого объема приводит к непроизводительной загрузке сети.

•          Возможно, что клиенту нужно узнать, существуют ли какие-то особые требования, связанные с конкретным ресурсом.

•          Возможно, агенту пользователя нужно узнать о возможностях прокси-сервера, находящегося на пути к Web-серверу.

•          Возможно, что прокси-серверу нужио прозопдировагь сервер, расположенный выше в цепочке к исходному серверу и претендующий на соответствие с НТТР/1.1, чтобы узнать, может ли он работать с конкретной возможностью НТТР/1.1, например, Expect.

По всем перечисленным причинам в НТТР/1.1 был введен повый метод OPTIONS. Запрос OPTIONS может быть направлен не только серверу-источпику, по и любому серверу на пути от отправителя к получателю. Метод OPTIONS, подобно методам GET и HEAD, является безопасным методом.

Например, чтобы получить список методов, поддерживаемых сервером, клиент может отправить следующий запрос OPTIONS:

OPTIONS * НТТР/1.1 Host: foo.com

Сервер может ответить так НТТР/1.1 200 0K

Allow: HEAD, GET, POST, TRACE, OPTIONS

Этот ответ показывает, что сервер поддерживает пять методов, перечисленных в заголовке ответа Allow. Заметьте, что URI, заданный в примере, представляет собой "*". Это означает, что клиента интересуют возможности сервера, а не какого-то конкретного URI. Для конкретного URI заголовок ответа Allow вернет набор методов, применимых к данному ресурсу.

Чтобы агент пользователя мог получить информацию о конкретном прокси-сер- вере, задействованном в цепочке передачи запроса, он должен убедиться с помощью метода OPTIONS, что данный запрос обрабогап нужным прокси-сервером. Обычно прокси-серверы пересылают запросы, которые они не могут обработать, исходному серверу. Для того чтобы клиенты могли получить ответ от конкретного прокси-сервера, в НТТР/1.1 был введен повый заголовок запроса. Клиент задает значение для заголовка запроса Max-Forwards, вынуждая каждый сервер в цепочке уменьшать это значение на единицу, пока оно не станет равным нулю, после чего соответствующий прокси-сервер должен ответить на запрос OPTIONS. Заголовок Max-Forwards был включен в протокол и для выбора в качестве цели прокси-сервера и для обнаружения циклов в цепочке прокси-серверов. Это поле похоже на поле времени жизни (TTL) в IP-пакетах (об этом говорилось в главе 5, раздел 5.1.4).

Рассмотрим следующий пример, где задан коикретпый сервер в цепочке передачи данных:

OPTIONS /bar НТТР/1.1 Host: foo.com User-Agent: Mozilla/2.0 Max-Forwards: 1

Этот запрос будет передай первому получателю, который вычтет единицу из заголовка Max-Forwards и передаст запрос следующему получателю. Второй иолуча- тель в ценочке должен ответить на запрос, так как значение Max-Forwards теперь равно нулю.

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

В дискуссиях, предшествовавших стандартизации, были сделаны попытки разрешить в ответах на запросы с заголовком OPTIONS возвращать информацию о совместимости, например, о совместимости с конкретной версией стандарта или песо- вместимости по отношению к одной из его возможностей. Однако из-за неопределенности связанной с термином совместность и из-за увеличения сложности, эта возможность не была введена в HTTP. Было добавлено расширение в виде DAV, заголовка для расширения HTTP, называемое WebDAV [GWF+99J, которое обеспечивает внесение изменений в ресурсы и управление версиями. Эта тема кратко обсуждается в главе 15 (раздел 15.5.2). WebDAV позволяет осуществлять удаленную разработку Web-контента с помощью набора методов, заголовков, запросов, ответов и форматов тела содержимого. Сервер WebDAV при получении запроса с заголовком OPTIONS может перечислить свои возможности с помощью заголовка DAV. Например, DAV:1 означает, что сервер удовлетворяет всем обязательным требованиям (уровень требований MUST), но не поддерживает блокировку. Заголовок DAV:1, 2 означает, что сервер поддерживает в том числе и блокировку.

МЕТОД TRACE

Метод TRACE, введенный в НТТР/1.1, позволяет клиенту узнать содержание сообщения, которое было действительно принято получателем. В отличие от метода OPTIONS, который позволяет клиенту узнать о возможностях сервера, метод TRACE побуждает сервер вернуть копию полученного сообщения.

В методе TRACE все содержимое сообщения-запроса сервер возвращает отправителю в качестве содержимого тела ответа. Например, если клиент сделал следующий запрос:

TRACE /bar НТТР/1.1 Host: foo.com User-Agent: Mozilla/2.0

результатом должен быть следующий ответ:

НТТР/1.1 200 0K Content-type: message/http

TRACE /bar НТТР/1.1 Host: foo.com User-Agent: Mozilla/2.0

Телом ответа должно быть полное HTTP-сообщение, полученное целевым сервером. Конечно, как и в любом HTTP-ответе, здесь есть заголовки и тело содержимого. Заголовок Content-type используется, чтобы указать, что ответ на запрос с методом TRACE имеет тип message/http. Тип message/http указывает, что тело ответа является HTTP-запросом или ответом и что он подчиняется соответствующим соглашениям MIME для данного типа (например, пределыюму значению длины строки и допустимым схемам кодирования).

Такого рода обратная связь на прикладном уровне (отправка запроса и получение его обратпо) не является чем-то новым, имеющимся только в HTTP. В других протоколах есть похожие механизмы — один из наиболее известных traceroute [Jac] (см. главу 5, раздел 5.1.4). Команда traceroute отслеживает маршрут, который проходит IP-пакет предназначенный хосту, путем посылки тестовых UDP-пакетов с различными значениями TTL и затем осуществляя прием по протоколу Internet Control Message Protocol (ICMP) ответов TIME_EXCEEDED, приходящих от маршрутизаторов на пути следования пакета.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100