Методы запроса НТТР/1.0

Метод запроса уведомляет HTTP-сервер, какое действие следует выполнить пад ресурсом, идентифицируемым URI запроса (т.е. URI, указываемом в строке запроса). Наиболее часто используется метод GET, который осуществляет выборку текущего содержимого ресурса, идентифицируемого URI. Хотя в НТТР/1.0 определены только три метода (GET, HEAD, POST), в некоторых версиях клиентов и серверов, поддерживающих НТТР/1.0, были реализованы и другие методы, а именно: PUT, DELETE, LINK и UNLINK. Все семь методов уже применялись в различных реализациях на момент появления спецификации НТТР/1.0. Поскольку методы LINK и UNLINK не входят в стандарт НТТР/1.1, они не будут подробно рассматриваться.

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

•          Метод запроса включается в клиентский запрос вместе с несколькими заголовками и URI.

•          Метод применяется к ресурсу исходным сервером, после чего генерируется ответ. Ответ состоит из кода ответа, метаданных о ресурсе и других заголовков ответа.

Имейте в виду, что промежуточное звено, такое как кэширующий прокси-сервер, получающий запрос и возвращающий кэшированный ответ, не применяет метод.

Двумя важнейшими характеристиками метода являются безопасность и идемпотентность. Метод запроса, который лишь просматривает состояние ресурса (например, получает текущее содержимое), считается безопасным методом. Метод, который способен изменить состояние ресурса, не является безопасным. Идемгютепт- иый метод, с другой стороны, имеет то свойство, что побочные эффекты для запроса являются точно такими же, что и для множества идентичных запросов. Другими словами, если последовательно выдается несколько идентичных запросов, применение метода к ресурсу либо не дает никаких побочных эффектов, либо дает одинаковый побочный эффект во всех случаях. Предсказуемость воздействия метода на ресурс является полезной для определения, должен ли ресурс поддерживать метод. Кроме того, если последовательность запросов идемнотептна, и если соединение было неожиданно закрыто, для клиента будет иметь смысл повторить набор запросов.

Ниже описываются методы НТТР/1.0.

GET

Наиболее популярным на сегодняшний день является метод GET. Запрос GET применяется к ресурсу, задаваемому URI, а генерируемым ответом является текущее значение ресурса. Этот ответ возвращается обратившемуся с запросом клиенту. Если URI указывает на статический файл, запрос GET обычно приводит к чтению файла и возврату его содержимого. Если URI указывает на программу, то в теле ответа возвращаются данные (если они имеются). Метод GET является безопасным и идемпотептпым. Запрос на CGI-pecypc, например, может вызвать изменение ресурса при применении к нему метода GET. Поскольку такой побочный эффект соответствует намерениям пользователя, метод считается безопасным.

Запрос GET может содержать параметры, которые формируются на основе данных, введенных пользователем. Это часто имеет место при запросе CGI-pecypca. Например,

GET http://www.altavista.com/cgi-bin/query?q=foo

передает пользовательскую строку запроса ("foo") ресурсу http://www.altavista.com/ cgi-bin.

Запрос GET, содержащий модификатор запроса, может привести к выполнению другого действия. Например, методу GET может быть предписано выбирать ресурс только в том случае, если время последней модификации запрашиваемого ресурса больше, чем значение, указанное в заголовке If-Modified-Since. Таким образом, запрос GET на ресурс /foo.html от клиента НТТР/1.0

GET /foo.html НТТР/1.0

может дать результат, отличный от того, который дает запрос

GET /foo.html НТТР/1.0

If-Modified-Since: Sun, 12 Nov 2000 11:12:23 GMT

в зависимости от того, когда ресурс /foo.html был в последний раз модифицирован на исходным сервере. Модификатор запроса If-Modified-Since используется для снижения числа обращений к сети и умепьшепия времени ожидания пользователем ответа, генерируемого и отправляемого исходным сервером. Если ресурс не был модифицирован с момента времени, указанного в заголовке If-Modified-Since, сервер отправляет код ответа, указывающий на это, не сопровождая ответ телом содержимого. Отметим, что знание времени последней модификации упрощает работу с периодически изменяемыми файловыми ресурсами. Для динамически генерируемого ресурса знание времени последней модификации особого значения не имеет. В НТТР/1.0 имеется несколько полезных модификаторов запроса. В НТТР/1.1 был добавлен еще ряд модификаторов, как мы увидим в следующей главе.

Метод запроса GET не имеет тела запроса. Если тело запроса присутствует, серверами оно игнорируется.

HEAD

Метод HEAD был задуман для получения метаданных, ассоциированных с ресурсом. В результате выполнения запроса HEAD тело ответа не возвращается. Однако метаданные, возвращаемые сервером, могут оказаться теми же метаданными, которые были бы возвращены, если бы методом запроса был GET. Например, запрос HEAD для получения метаданных, ассоциированных с ресурсом /foo.html,

HEAD /foo.html НТТР/1.0

может вернуть

НТТР/1.0 200 0K

Content-Length: 3219

Last-Modified: Sun, 12 Nov 2000 11:12:23 GMT

Content-Type: text/html

Ответ состоит из строки состояния (НТТР/1.0 200 OK), указывающей на успешное выполнение запроса, и Группы заголовков, представляющих метаданные для ресурса /foo.html. В этом примере метаданные содержат информацию о длине содержимого, времени последней модификации ресурса и типе ресурса. Метод HEAD безопасен и идемпотентеп.

Метод HEAD в основном используется при отладке для серверов с относительно малой загруженностью, а также для определения, был лн ресурс изменен с момента последней его загрузки. Метаданные могут кэшироваться пли использоваться для обновления имеющихся кэшированных данных, если было установлено изменение ресурса. В НТТР/1.0 изменение может быть обнаружено путем анализа значений полей заголовков Last-Modified или Content-Length. Однако в связи с тем, что ресурс может быть изменен без изменения его длины, анализ одного только поля заголовка Content-Length не гарантирует обнаружения изменении.

В НТТР/1.0 метод HEAD нельзя использовать с модификаторами запроса, такими как If-Modified-Since. Это ограничение было снято в НТТР/1.1.

Метод запроса HEAD также не имеет тела запроса. Если тело запроса присутс твует, серверами оно игнорируется.

POST

В отличие от методов GET и HEAD, которые используются для извлечения информации, метод POST применяется главным образом для модификации имеющегося ресурса или передачи данных обрабатывающему их процессу. Тело запроса содержит данные. Исходный сервер в зависимости от URI запроса, разрешает выполнение определенных действий. Метод POST может изменять содержимое ресурса, поэтому не может считаться безопасным методом. Поскольку побочные эффекты множества идентичных запросов могут отличаться, метод POST не является идем- потеитпым методом.

Чтобы модифицировать ресурс, пользователь должен иметь необходимые полномочия. Не все пользователи могут обладать правами на изменение ресурса. Если пользователь имеет право на изменение ресурса, исходный сервер примет новую версию ресурса от клиента. Другое применение метода POST состоит в получении тела запроса сервером и использовании его в качестве входных данНых для программы, идентифицируемой URI запроса. Такой программой может быть почтовая служба или менеджер доски объявлений, который создает файл, доступный другим приложениям, таким как программа для чтения электронной почты или новостей. Бывает также, что в результате выполнения запроса POST ресурсы не изменяются и не создаются. В этих случаях тело запроса трактуется как входные данные для программы, которая использует эти данные.

Рассмотрим пример:

POST /foo/bar.cfm НТТР/1.0 Content-Length: 143

<тело содержимого>

Если принимающий сервер может успешно применить метод к ресурсу, он возвращает ответ, указывающий на успешное выполнение запроса. Предположим, что /foo/bar.cfm представляет собой ресурс, который не существует на исходном сервере. Сервер создаст ресурс и отправит ответ, указывающий на то, что ресурс был создай. Если, с другой стороны, /foo/bar.cfm является программой, ожидающей входных данных, то 143-байтное тело содержимого трактуется как входные данные для программы. Любой выход, генерируемый программой, отправляется обратно пользователю как тело ответа. Следует иметь в виду, что заголовок Content-Length для запроса POST является обязательным, поскольку оп дает возможность принимающему серверу НТТР/1.0 определить, что получен весь запрос.

Метод GET также может быть использован для отправки входных данных программе. Однако в использовании для этих целей методов GET и POST имеются различия. В запросе GET входные данные включаются в URI запроса. Предположим, что пользователь заполнил два поля в форме для поиска: искомая строка и база данных, в которой следует вести поиск. Например, запрос

GET /search.cgi?string=iktinos&db=greek-architects НТТР/1.0

демонстрирует, как данные, введенные пользователем в форме, могут быть включе- пы в URI запроса. Здесь запрашиваемым с помощью метода GET ресурсом является search.cgi, которому передаются значения двух полей (string и db). При использовании метода POST этот же запрос выглядел бы следующим образом:

POST /search.cgi НТТР/1.0 Content-Length: 34 CRLF

query iktlnos db greek-architects

Оба запроса выдадут один и тот же ответ. Предположим, однако, что на пути между клиентом и исходным сервером имеются посредники. Посредник обычно регистрирует проходящие через пего запросы. Но в то время как URI запроса скорее всего будет занесен в журнал регистрации, тело содержимого вряд ли будег зарегистрировано. Таким образом, в случае запроса GET искомая строка будет занесена в журнал, а в случае запроса POST — нет. Некоторые посредники и серверы ограничивают длину подлежащего обработке URI, и это может стать еще одной причиной, чтобы предпочесть метод POST методу GET при передаче данных форм.

PUT

Метод PUT схож с методом POST в том, что выполнение метода обычно приводит к изменению ресурса, идентифицируемого URI запроса. Если запрашиваемый через URI ресурс не существует, он создается, а если ресурс существует, то модифицируется. При использовании метода PUT в результате выполнения запроса изменяется сам идентифицируемый URI ресурс.

В НТТР/1.0 метод PUT официально не определен. На момент выхода RFC 1945 несколько реализаций клиентов и серверов уже начали использовать этот метод, поэтому метод PUT (наряду с методами DELETE, LINK, UNLINK) был вкратце уно- мяпут в приложении RFC 1945. В главе 7 (раздел 7.12.1) мы подробнее поговорим о различиях между методами PUT и POST. Метод PUT не является безопаспым методом. Метод PUT является идемпотептпым, поскольку последовательность идентичных запросов PUT будет в каждом случае давать одно и то же содержимое, а побочные эффекты каждый раз будут одинаковыми.

DELETE

Метод DELETE используется для удаления ресурса, идентифицируемого URI запроса. Метод предоставляет возможность дистанционного удаления ресурсов. Однако принимая во внимание суть этого действия, исходные серверы контролируют, было ли в действительности выполнено запрашиваемое действие, и когда это произошло. Сервер может отправить ответ об успешном выполнении, в действительности не удалив ресурса. Имеется два вида ответов для успешного выполнения: один указывает на приемлемость запроса для последующей обработки, а другой указывает на реалыюе выполнение запроса. Подобная гибкость важна для исходных серверов при принятии решения, когда и как планировать действие, а гакже чтобы не приходилось держать открытым соединение с клиентом до тех пор, пока действие реалыю не будет завершено. Метод DELETE не является безопасным методом. Подобно методу PUT, метод DELETE является идемпотептпым.

LINK И UNLINK

Метод LINK позволяет создавать связи между запрашиваемым URI и другими ресурсами. После того, как такая связь создапа, Можно запрашивать ресурсы но одному и тому же URI запроса. Метод UNLINK используется для удаления связей, созданных посредством метода LINK.

Хотя эти методы были определены в приложении НТТР/1.0, они не получили широкого распространения и в НТТР/1.1 отсутствуют.

Источник: 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