На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

ПРОЧИЕ МЕТОДЫ HTTP

Кроме методов GET, POST и HEAD, в протоколе HTTP имеется еще несколько менее используемых методов: CHECKIN, CHECKOUT, DELETE, LLNK, PUT, SEARCH, SHOWMETOD, SPACEJUMP, TEXTSEARCH и UNLLNK. Отметим, что не все серверы полностью поддерживают все вышеперечисленные методы. В таблице 6.5 приведены описания всех методов.
Метод
Описание
CHECKIN CHECKOUT
DELETE LINK
Похож на метод PUT. Он убирает блокировку, установ­ленную при помощи метода CHECKOUT. Большинство клиентов используют PUT, а не CHECKIN.
Похож на метод GET, за исключением того, что он блокирует объект от изменений его другими пользовате­лями. Большинство клиентов используют GET, а не
CHECKOUT.
С помощью этого метода можно удалить файл с конкрет­ным URL
С помощью этого метода можно связать существующий
объект Web с другими объектами в сети. В настоящее время ни один из Web-серверов не пользуется этим мето­дом, но он зарезервирован для использования в будущем. PUT Клиенты используют метод PUT идя записи файла по указанному адресу (URL). Если файл с тем же име­нем и расширением уже существует, то он заменяется
на новый. Таким образом клиенты загружают информа­цию на сервер Web. Данные хранятся внутри передавае­мого клиентом файла.
SHOWMETOD       Применяется для приема информации о конкретном методе (о том, как метод применяется к определенному объекту).
SPACEJUMP Клиенты используют этот метод для обработки запроса, указанного в терминах координат в рамках объекта. TEXTSEARCH       Применяется для запроса специфического объекта. UNLINK .            Используется для того, чтобы убрать ссылку. В настоя­щее время серверы Web не воспринимают этот метод, _но он зарезервирован для использования в будущем._
Примечание. Кроме описанных выше методов в HTTP реализована поддержка методов TRACE и OPTIONS. За более подробной информацией об этих методах я отсылаю вас к документу RFC 2068. Чтобы найти его, воспользуйтесь ссылкой, расположенной на странице издательства Jamsa Press http://www.jamsa.com.
ОСНОВНЫЕ поля ЗАГОЛОВКА
Некоторые поля заголовка используются и в запросах, и ответах, но не относят­ся к коммуникационным операциям с клиентом и сервером или передаваемым данным. Среди них - основной заголовок. Он состоит из полей Date, MIME-version (обычно 1.0) и Pragma. Эти поля можно воспринимать как обычные перемен­ные. Один основной заголовок может содержать несколько полей.
ПОЛЕ DATE
В поле Date содержится дата в формате HTTP, и поэтому она должна соответ­ствовать соглашениям о дате HTTP. Обычно в этом поле содержится информа­ция о дате и времени создания документа, например:
Date: Wed, 3 Sep 1997 08:12:31 GMT
ПОЛЕ MIME-VERSION
Наличие такого поля означает, что полностью удовлетворяет протоколу MIME. Для HTTP 1.0 версией MIME по умолчанию является «1.0», на­пример:
MIME-version: 1.0
ПОЛЕ PRAGMA
Поле Pragma содержит в себе «инструкции» для устройств-приемников (вроде шлюза), расположенных по всему пути следования информации. Такие «инст­рукции» в основном состоят из указаний на то, что «необходимо пропустить запрос». Другими словами, даже если шлюз кэширует (сохранит у себя копию)
результат запроса, он обязан просто пропустить запрос через себя к серверу и не обрабатывать его. Такая процедура обеспечивает достоверность ответа сервера на запрос броузера. Кроме того, ваш броузер получит новую копию ресурса, если предыдущая устарела или «запорчена». показаны различия в действиях шлюза, работающего по «инструкции» и без нее.
При наличии поля Pragma протокол HTTP просто определяет синтаксис запро­са. Если существует копия из кэша, то она не используется. Пример поля Pragma:
Pragma: cache
без «инструкции»
с «инструкцией»
неизмененная
локальный удаленный удаленный
кэш сервер сервер
Работа шлюза по «инструкции» и без нее.
ПОЛЯ   ЗАГОЛОВКА ЗАПРОСА
Поля заголовка запроса (Request-Header) позволяют клиенту указать Web-серверу дополнительную информацию о запросе и о себе. Все поля подобного типа являются необязательными и включают в себя: Accept, Authorization, From, If-Modified-Siпс Referer и User-Agent. Все они описаны в последующих разде­лах. Кроме того, большинство серверов работают с неизвестным полем запроса как с полем заголовка объекта. показано, как перед дополни­тельной обработкой сервер считывает поле заголовка запроса.
документ
Сервер считывает поле заголовка запроса.
Примечание. Можно расширить число полей заголовка, добавляя к этому списку новые поля, но это возможно лишь при изменении версии протокола HTTP.
ПОЛЕ ACCEPT
Когда клиент взаимодействует с сервером, он посылает ему поле Accept, где указывает список поддерживаемых им типов и расширений MIME. Обычно такое
поле используется, если необходимо получить нестандартный тип данных. В большинстве случаев значением поля Accept является */*, что означает способ­ность клиента принять и обработать любые типы и расширения MIME. Другой пример для поля Accept:
Accept; text/html
Примечание. В будущем приложения смогут поддерживать поля Accept-Encoding и Accept-Language, где указывается информация о кодировании или сжатии инфор­мации, а также о языке.
ПОЛЕ Authorization
Если клиент пытается осуществить неавторизованный доступ к серверу, после­дний посылает ему код статуса 401. Обычно после этого клиент использует поле Authorization заголовка запроса, с тем чтобы ответить серверу после приема тако­го кода статуса. Другими словами, клиент проводит процесс регистрации на сервере Web. Обычно регистрация происходит один раз для каждой схемы под­ключения. Может случиться так, что клиенту необходимо регистрироваться не­сколько раз и с разными реквизитами, если он использует несколько служб одного сервера (например, HTTP и FTP). Пример:
Authorization:  Basic aSGWcaK23
Обратите внимание: строка aSGWcaK2. представляет собой зашифрованные имя и пароль пользователя.
ПОЛЕ FROM
При помощи поля From серверу передаются адреса электронной почты клиента с целью протоколирования работы. В таком случае сервер (или его администра­тор) может связаться с клиентом в случае возникновения каких-либо проблем.
Поле From особенно полезно в случае, когда необходимо сообщить владельцу
робота-агента о его неисправности. (Робот представляет собой утилиту поиска в Web.) Пример:
From: lklander@jamsa.com
ЛОЛЕ   If- MoDiFiED-SiNCi:
Клиенты используют поле If-Modified-Sin совместно с методом GET, чтобы наложить какие-то условия на запрос. Если требуемый ресурс не был изменен после даты, указанной в этом поле, то сервер не высылает его копию. Вместо этого он вставляет код статуса 304 (нет изменений) в тело объекта. Клиенты используют метод GE7с условиями, чтобы копировать только свежую информа­цию. Отметим, что используемые в этом поле данные должны записываться в том же формате, что и информация поля Date. Пример:
If-Modified-Since: Моп, 07 May 1996 19:43:31 GMT
ПОЛЕ REFERER
Клиенты используют поле Referer для информирования сервера Web об адресе ресурса (URI), от которого они перешли к текущему объекту. Подобная инфор­мация нужна, для того чтобы сервер мог сгенерировать список обратных ссы­лок, оптимизировать кэширование и т, д. Другими словами, это поле содержит информацию об объекте, который был использован клиентом до получения до­ступа к текущему.
Кроме того, это позволяет серверу освободиться от устаревших или неправиль­ных ссылок. Клиент не должен заполнять поле, если переход к объекту осуще­ствляется не по ссылке (например, адрес введен с клавиатуры). Пример:
Referer: http://www.j amsa.com/catalog/catalog.htm
ПОЛЕ USER-AGENT
В поле User-Agent содержится информация о клиенте по поводу того, является ли он роботом, странником или даже броузером. Роботы и странники — это автоматизированные программы, занимающиеся поиском и извлечением инфор­мации из Web. Сервер использует поле User-Agents статистических целях, напри­мер, для подсчета числа посещений сервера (hit). Кроме того, оно применяется для отслеживания нарушений в протоколах, автоматического распознавания бро­узера и для компоновки ответа с учетом ограничений броузера клиента. Хотя
это и необязательно, броузер почти всегда включает это поле в запросы. Пример:
User-Agent: Mozilla/2.0

ПОЛЯ   ЗАГОЛОВКА ОБЪЕКТА
Поля заголовка объекта (Entity-Header) определяют дополнительную метаинфор-мацию, т. е. краткое описание тела объекта (данных). Другими словами, мета-
информация обеспечивает получателя более подробными сведениями о том, как
лучше работать с сообщением. Если сообщение не содержит данных, поля заго­ловка объекта содержат дополнительную информацию о запрашиваемом ресур­се. Заголовок объекта может содержать следующие поля: Allow, Content-Encoding, Content-Lenght, Content-Type, Expires и Last-Modified. схематич­но показано, как используется поле заголовка объекта.
Если поле заголовка неизвестно получателю, он отбрасывает его. Если такое поле неизвестно серверу-посреднику, он перенаправляет его далее. Сервер-по­средник представляет собой программу, выполняющую функции посредника и обычно загруженную на маршрутизаторе; она берет на себя функции пересылки запросов как от клиента, так и от сервера.
ja головок объекта
содержание объекта
документ
содержание объекта
сервер
броузер
В поле заголовка объекта описывается специфика полученного документа.
ПОЛЕ ALLOW
В поле Allow перечислены все операции HTTP, доступные для текущего ресур­са. Можно сказать, что оно устанавливает «соглашение о методах» между кли­ентом и сервером Web. Другими словами, с его помощью приложения могут сообщить о доступных методах для текущего ресурса. Поле Allow не допускается использовать совместно с методом POST, и получатель в таких случаях должен игнорировать его.
Хотя клиент может сформировать и выслать поле Allow, возможно использова­ние и не указанных в нем методов. Поэтому с точки зрения клиента он не огра­ничен только методами, оговоренными в поле Allow. Приведем пример поля Allow:
Allow:  GET, HEAD
Стоит отметить несколько важных моментов, связанных с этим полем. Во-пер­вых, сервер-посредник не должен изменять это поле, даже если он не понимает некоторые из указанных методов. Это происходит потому, что клиент может связаться с сервером по другому каналу. Если сервер-посредник изменит заго­ловок, связь клиент/сервер будет нарушена. Во-вторых, поле Allow не содержит информации о том, какие методы может выполнить сервер. Клиент не должен полагать, что сервер обработает информацию теми методами, что указаны в поле Allow.
ПОЛЕ CONTENT-ENCODING
Приложения используют поле для ссылки на метод сжатия данных, составляющих тело объекта. Приложение, применяющее это поле, в точ­ности сохраняет исходный формат документа. Пример:
Content-Encoding: x-gzlp
Поле Content-Encoding представляет собой один из параметров ресурса, опреде­ляемого URI. В большинстве случаев ресурс хранится на сервере уже в сжатом виде и разворачивается только при обращении клиента или в других аналогичных случаях.
ПОЛЕ CONTENT-LENGTH
Поле Content-Length указывает на размер тела объекта, принимаемого сервером Web от клиента по методу GET. При использовании метода HEAD протокола HTTP оно содержит размер тела объекта, который может быть послан по запро­су метода GET. Для метода POST в поле Content-Lenght указывается размер тела объекта. Размер его определяется в байтах.
Наличие поля Content-Lenght vis является необходимым для HTTP, но в нем можно хранить размер тела объекта. Это иногда требуется при программировании. Пример:
Content-Lenght: 3495 Значение поля Content-Lenght всегда больше или равно 0.
ПОЛЕ CONTENT-TYPE
В поле Content-Type указывается тип тела объекта, высылаемого в ответ на за­прос GET. Если используется метод HEAD, то применяется аналогичный тип.
Пример:
Content-Type: text/html
ПОЛЕ EXPIRES
В поле Expires указываются дата и время, после которых информация считается устаревшей. Как собственник своих ресурсов, сервер всегда может проверить их актуальность. Клиенты, работающие с кэшем, включая сервер-посредник, не должны хранить копии объектов после указанных даты/времени. Наличие поля
не означает, что информация изменится в ближайшее время. Однако если есть хотя бы малейшая вероятность изменения ресурсов, сервер должен добавлять
информацию в поле Expires. Пример использования поля:
Expires: Fri, 22        1997 16:00: ОС GMT
Поскольку значением поля является дата, то Expires не имеет значения по умолча­нию. Если дата в Expires меньше либо равна значению поля Date основного за­головка, то клиент не должен держать ее в кэше. Если информация по своей сути является динамически изменяемой, поле Expires должно отражать такую картину.
Серверы не могут при помощи поля Expires заставить клиентов ускорить обновле­ние или повторную загрузку ресурса. Поэтому оно применяется в основном при кэшировании ресурсов. Если клиент в текущее время использует ресурс и этот ресурс устарел, то автоматического обновления информации может не произойти.
Во многих броузерах по аналогии с Netscape Navigator имеется возможность про­смотреть «историю» работы при помощи кнопки Back или вызвать список уже просмотренных документов Web. По умолчанию поле Expires не имеет отноше­ния к этому механизму. До тех пор, пока пользователь не сконфигурирует броузер
так, чтобы обновлялась устаревшая информация, броузер будет выводить на эк­ран старые документы Web.
Примечание. При написании программ вы должны быть готовы к ошибкам в полях заголовка. Используя поле Expires в качестве примера, ваша программа может об­работать нулевое значение или неправильную дату. Обе эти ошибки означают, что информация устарела. Хотя такие данные не подходят по стандарту HTTP, ваша программа может работать с ними и обрабатывать такого рода конфликты.
ПОЛЕ EXTENSION-HEADER
Поле Extension-Headei позволяет определить еще один заголовок для объекта без изменений в протоколе HTTP. Однако не все приложения могут работать с та­кими заголовками, поэтому необходимо очень аккуратно применять его.
ПОЛЕ LAST-MODIFIED
С помощью поля Last-Modified серверы помечают, когда последний раз изменя­лась информация об объекте. Если данные имеют более раннюю дату, чем зна­чение поля Last-Modified, они могут считаться устаревшими.
Клиент может определить, когда ресурс устаревает, основываясь на информа­ции от сервера. Для файлов сервер может использовать время и дату последнего их изменения. Для объектов, состоящих из нескольких частей данных, сервер использует дату самого последнего изменения одного из компонентов. В слу­чае, когда используется доступ к базам данных, сервер включает в поле Last-Modified значение даты/времени последнего изменения записей. Вообще гово­ря, выбор технологии обновления для различных типов ресурсов является пре­рогативой сервера.
Сервер не должен посылать в поле Last-Modified более позднюю дату, чем дата самого сообщения. Другими словами, это поле не содержит дат из будущего.
Пример:
•    Last-Modified: Fri, 22 Aug   1997 12:45:26 GMT
ОТВЕТ СЕРВЕРА
Как вы знаете, в отличие от версии HTTP 0.9, где использовались простые ответы, текущая версия HTTP 1.0 работает с полными ответами, которые тре­буют наличия хотя бы строки состояния, где указана версия HTTP, код статуса и тема ответа. В следующих разделах мы подробнее рассмотрим заголовок пол­ного ответа HTTP.
ПОЛЯ за голо в к.   ОТВЕТА HTTP
С помощью полей заголовка ответа (Response-Header) сервер передает инфор­мацию, не отраженную в строке состояния. Они содержат информацию о сервере,
а не о передаваемых данных, например, поля, местонахождение сервера, его название и способ регистрации. Клиент должен рассматривать не­известные ему поля заголовка ответа как поля заголовка передаваемого объекта (см. предыдущие разделы).
ПОЛЕ LOCATION
В поле Location определяется точный адрес ресурса, на который указывает URI в строке запроса. Другими словами, для определения значения этого поля сер­вер использует строку запроса клиента, чтобы найти абсолютный URI. Это необ­ходимо в случае, если клиент указал относительный адрес. Сервер располагает выделенным абсолютным URL для целей маршрутизации. Вот пример исполь­зования поля:
Location: http://www.j amsa.com/catalog/catalog.htm
ПОЛЕ SERVER
Поле Server содержит информацию о программном обеспечении сервера, обра­батывающего текущий запрос. В нем указывается как ПО сервера, так и наибо­лее важные утилиты и компоненты. В целях защиты информации можно не указывать версию программного обеспечения, чтобы обезопасить себя от атак
хакеров на устаревшие версии. Пример: Server: CERN/3.О libwww/2.17
Кроме того, если данные проходят через сервер-посредник, в поле Server его версии не добавляются.
ПОЛЕ WWW-AUTHENTICATE
Сервер использует поле WWW-Authenticate если код статуса равен 401 (неавтори­зованный доступ). HTTP предоставляет несложный механизм работы с регистра­цией на серверах Web. Клиент использует аналогичные механизмы регистрации.
ТЕЛО ОБЪЕКТА
Когда клиент либо сервер используют HTTP 1.0 для пересылки данных в запросе либо ответе, они должны определить формат и способ сжатия, используя поля
заголовка объекта. Как вы уже знаете, тело объекта состоит из байт (восемь бит) и может содержать 0 и более байт.
Приложения могут включать данные в запрос, если только метод позволяет это (например, POST). Программа определяет, есть ли данные, по ненулевому зна­чению поля Content-Length. Запрос HTTP, содержащий данные, должен ис­пользовать правильное значение размера объекта. показано, как сервер просматривает поле чтобы определить, содержит ли запрос данные.
сервер
заголовок запроса тело заголовка
размер содержимого
Сервер просматривает поле Content-Length.
Для ответных сообщений программа должна проверить как метод запроса, так и код статуса ответа, чтобы определить наличие тела объекта. Все ответы на за­просы с HEAD не должны включать в себя тело объекта, даже если поле Content-Lenght имеет ненулевую длину, а в Content-Type указан правильный тип данных. Аналогично тело объекта не включается в ответ, если коды статуса равны 204 (нет содержимого) и 304 (без изменений).
Когда в сообщении присутствует тело объекта, приложение может определить его тип, используя поля Content-Type и которые определяют двухуровневую модель:
entity body =    Content-Encoding(Content-Type(data))
Поле Content-Type указывает тип данных тела объекта. В поле Content-Encoding обычно указывается информация о типе сжатия данных. По умолчанию, здесь стоит значение «без сжатия».
В поле Content-Type по умолчанию нет значения. Оно используется только в случае, если запрос был простым. Для того чтобы определить тип данных, кли­ент должен изучить содержимое объекта и его адрес URL. Если не удается опре­делить тип данных, по умолчанию используется «application/octet-stream».
Когда программа включает тело объекта в сообщение, принимающая сторона определяет его длину несколькими способами. Если присутствует ненулевое зна­чение поля заголовка объекта, то его значение и есть длина тела объекта в байтах. В противном случае клиент определяет длину тела объекта после того, как сервер закрывает соединение.
Клиент не может сам инициировать разрыв соединения, поскольку в таком слу­чае он не позволяет серверу ответить на запрос. Поэтому запрос HTTP должен содержать правильное значение поля Content-Length заголовка объекта. Если за­прос содержит данные, а их длина не указана и сервер самостоятельно не может вычислить ее, он возвращает код статуса 400 (неправильный запрос).
ПЕРЕДАЧА ДАННЫХ Web
Поскольку Internet является «транспортной системой» Web, передача данных Web - это синоним передачи данных Internet. Например, когда сервер Web
посылает данные клиенту, они путешествуют по Web посредством надежного коммуникационного протокола TCP.
Как известно, при использовании HTTP в сети передаются не только данные, но и информация о заголовках объектов, статусах кода и т. п. Коммуникацион­ная подсистема Internet разбивает эту информацию на пакеты для более эффек­тивной передачи. Понимание этого процесса поможет вам разрабатывать хоро­шие Web-программы и правильно использовать ресурсы Internet.
ПРИМЕР  ТРАНЗАКЦИИ HTTP
Следующий пример демонстрирует, какой запрос выслал Netscape Navigator 3.0 серверу издательства Press с целью получения документа
com/catalog/hacker/hacker, html:
GET /catalog/hacker/hacker. htm HTTP/1. 0 Accept: text/plain Accept: text/html ■ Accept: */*
If-Modified-Since Fri, 22 Aug 1997 06:17:33 GMT Referer: http://www.jamsa.com/catalog/catalog.htm User-Agent: Mozilla/3. 0 <CR/LF>
Текст этого примера указывает серверу вернуть броузеру страницу hacker.htm, расположенную на сайте www.jamsa.com. Кроме того, сервер должен принять определенные типы возвращаемых значений. И наконец, код указывает серверу не возвращать никаких данных, если страница не изменялась с 22 августа 1997 го­да — вместо нее будет использована копия из кэша. Каждый раз, когда пользо­ватель обращается за информацией, броузер посылает информацию заголовка.
Точно так же в ответ на запрос сервер посылает заголовок HTTP, и тело объекта (если того попросит броузер).
РЕЗЮМЕ
В этой главе мы детально рассмотрели HTTP — основной протокол Web. В следующих главах я расскажу о том, как использовать этот протокол и порож­денные им протоколы для защиты системы от нападений извне. Кроме того, вы узнаете, как хакер может воспользоваться HTTP для нанесения ударов по под­ключенной к Internet системе. Но прежде убедитесь, что усвоили следующее:
HTTP работает поверх TCP/IP и отвечает за передачу данных Web Internet.
S Для того чтобы работать со службами Web, необходимо установить соеди­нение с самим сервером по протоколу TCP/IP.
V MIME совместно с HTTP и TCP/IP позволяет вам посылать и принимать
файлы мультимедиа по Internet.
Можно посылать запросы серверу Web, используя броузер.
✓ URI и URL содержат адреса объектов Web.
HTTP обеспечивает методы, позволяющие управлять ресурсами.
Заголовки HTTP, строки запросов и коды статусов содержат массу ин­формации о данных, передаваемых в Web.
✓ Броузеры и серверы Web формируют архитектуру клиент/сервер и исполь­зуют обмен коммутируемыми пакетами по Internet.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика