Заголовки НТТР/1.0

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

Как мы выяснили в главе 5, каждый из протоколов нижних уровней имеет заголовки. В противоположность фиксированному формату заголовков IP и TCP, протоколы прикладного уровня имеют более свободный формат представления заголовков. В протоколах нижних уровней размер пакетов часто ограничивается из соображений производительности. Фиксированный формат заголовков протоколов нижних уровней гарантирует, что сообщения не будут произвольно увеличиваться в результате добавления заголовков. Для протоколов прикладного уровня такой проблемы не существует, добавление новых заголовков является типичным способом добавления новых функций.

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

НТТР-сообщение может иметь любое число заголовков, отделяемых символами CR и LF. Существуют определенные правила, связанные с передачей и интерпретацией заголовков сообщения по мере прохождения запроса или ответа в сети через серверы-посредники. Определенные типы сообщений запросов-ответов HTTP могут иметь обязательные заголовки. Большинство заголовков не являются обязательными, и Web-K0Mii0iieiiTbi добавляют их по онределенпым причинам. Web-комионенты могут игнорировать и игнорируют заголовки, которые не являются обязательными. Заголовки, описанные в спецификации, должны быть попятными для всех Web- компонентов: клиентов, серверов-посредников и исходных серверов.

Заголовок имеет общий синтаксис, в соответствии с которым имя и значение отделяются друг от друга символом двоеточия ":". Например, чтобы указать время создания сообщения, заголовок Date должен быть включен в сообщение примерно следующим образом:

Date: Thu, 23 Dec 1999 08:12:31 GMT

"Date" представляет собой ноле имени заголовка, а строка "Thu, 23 Dec 1999 08:12:31 GMT" — ноле значения. Вот пример заголовка с несколькими нолями значений:

Accept-Language: de-CH, en-US

Здесь поле имени — Accept-Language, а поля значений — de-CH и en-US.

В HTTP имеется иерархия заголовков. Заголовок сообщения в НТТР/1.0 является родовым именем для заголовка и может быть:

•   Обищм заголовком, используемым в сообщениях запросов и ответов.

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

•          Заголовком ответа, присутствующим в сообщении-ответе для предоставления дополнительной информации об ответе или для запроса дополнительной информации от пользователя.

•          Заголовком содержимого, присутствующим в сообщениях запроса и ответа. Заголовки содержимого используются для предоставления информации о содержимом, например, время последнего изменения. Если поле общего заголовка или поле заголовка запроса-ответа не распознается, оио трактуется как иоле заголовка содержимого.

Если заголовок не распознается получателем сообщения, он просто игнорируется. Однако если получателем является посредник, посредник должен переслать заголовок.

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

ОБЩИЕ ЗАГОЛОВКИ

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

•          Date. Общий заголовок Date указывает на дату и время создания сообщения. Заголовок Date имеет такой же синтаксис, что и строка даты/времени в стандарте для текстовых сообщений Internet (документ RFC 822, позднее обновленный документом RFC 1123). Дата в этом формате имеет следующий вид:

Date: Tue 16 May 2000 11:29:32 GMT

Хотя это наиболее предпочтительный формат, НТТР/1.0 разрешает использование двух других форматов (определенном в документе RFC 1036 н в формате asctime() стандарта ANSI С). Формат RFC 1036 выглядит следующим образом:

Date: Tuesday, 16-May-00 11:29:32 GMT

Формату RFC 1036 присуща проблема, связанная с представлением года двумя цифрами. Как видно из примера, значение года трактуется как 00 вместо 2000. Неоднозначность, связанная с разрешением использования второго формата на основе RFC 1036, была впоследствии устранена в повой версии протокола (НТТР/1.1) в результате усилий по решению проблемы двухтысячного года. В соответствии с форматом asctime() стандарта ANSI С дата записывается следующим образом:

Date: Tue May 16 11:29:32 2000

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

•          Pragma. Заголовок Pragma дает возможность отправлять директивы получателю сообщения. Директива — это способ указать для компонентов определенный вариант обработки запроса или ответа. Вообще директивы не являются обязательными для протокола, хотя в реальности есть несколько специфических директив, которым подчиняются большинство компонентов. Эта разница очень важна, поскольку, хотя протокол требует от компонентов пересылать директивы, он не обязывает компоненты следовать им, если они не являются уместными. Единственной директивой, определенной в протоколе, является

Pragma: no-cache которая ипформируег серверы-посредпики на маршруте следования сообщения не возвращать кэшированную копию; т.е. отправитель заинтересован в получении ответа непосредственно от исходного сервера. НТТР/1.0 не определяет назначение директивы Pragma: no-cache в сообщении-ответе.

ЗАГОЛОВКИ ЗАПРОСА

Заголовок запроса может использоваться клиентом для отправки информации с запросом или задания ограничений при обслуживании запросов сервером. Передаваемая информация может содержать дополнительные сведения о клиенте, например, идентификационные данные пользователя или агента пользователя, либо информацию для авторизации, необходимую, чтобы запрос был обработан исходным сервером. В НТТР/1.0 определены пягь заголовков запроса:

•          Authorization. Заголовок Authorization иснользуется агентом пользователя для включения соответствующих полномочий, необходимых для доступа к ресурсу. Для некоторых ресурсов сервера доступ разрешается только при наличии соответствующих полномочий. Вот пример заголовка Authorization:

Authorization: Basic YXZpYXRpS29IDizM1NA==

Здесь Basic (обычная) обозначает схему аутепгификации, согласно которой данные представляются в виде идентификатора пользователя и пароля. Строка YXZpYXRpS29IDizMlNA== представляет собой кодированные идентификатор пользователя и пароль в формате Base64 [FB96aJ. Формат использует простой алгоритм кодирования и декодирования, а закодированные данные не па- много длиннее исходных данных. Другие допустимые в HTTP схемы аутентификации предусматривают шифрование на транспортном уровне.

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

From: gorby@moskvax.com

Следует заметить, что использование заголовка From нежелательно, поскольку он нарушает конфиденциальность пользователя, особенно если это делается без его ведома.

•          If-Modified-Since. Заголовок If-Modified-Since является примером условного заголовка, указывающего, что запрос может быть обработан различными способами в зависимости от Значения, заданного в поле заголовка. Если предыдущий ответ от сервера был кэширован клиентом или посредником, значение, заданное в заголовке ответа Last-Modified, используется в последующем запросе GET в качестве аргумента в заголовке If-Modified-Since. Например, для следующего запроса:

GET /foo.html НТТР/1.0

If-Modified-Since: Sun, 21 May 2000 07:00:25 GMT

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

или fstat() в UNIX). Если ресурс не изменился с указанного времени Sun, 21 May 2000 07:00:25 GMT, сервер просто вернет ответ 304 Not Modified. Для резко меняющихся ресурсов эго поможет избежать неиужпых пересылок данных. Серверу не нужно повторно генерировать ресурс, и время ожидаиия на стороне пользователя снижается, поскольку клиент может получить содержимое локально.

•      Referer. Поле заголовка Referer1 дает возможность клиенту включать URI ресурса, от которого был получеп запрашиваемый URI. Например, предположим, что пользователь посещает Web-страницу http://www.cnn.com и щелкает на гиперссылке на ресурс http://www.disasterrelief.org/Disasters/world- glance.html на этой странице. Заголовок Referer в запросе, передаваемом на http://www.disasterrelief.org, будет содержать строку http://www.cnn.com:

GET /Disasters/worldglance.html НТТР/1.0 Referer: http://www.cnn.com

Польза от применения поля Referer состоит в выявлении устаревших гиперссылок. Однако чаще всего оно становится источником нарушения конфиденциальности пользователя. Рапее (глава 2, раздел 2.6.4 и глава 3, раздел 3.7) мы говорили о проблемах нарушения копфидепциальпости, связанных с применением cookies и посредников. Поле Referer представляет собой заголовок, который может быть использован исходным сервером для отслеживания действий пользователя через журпал регистрации.

Есть и худшие ситуации. Предположим, что с помощью формы, использующей метод GET (см. раздел 6.2.2) передается номер кредитной карты пользователя. Допустим, что сама форма передается безопасным способом (скажем, с применением SSL), а полученная после выполнения запроса с формой страница содержит ссылку на другую страницу, возможно, находящуюся на сервере S. Теперь, если пользователь переходит к этой странице, журнал регистрации сервера S будет содержать запись с полем Referer, содержащим номер кредитной карты пользователя.

Кроме того, сервер может осуществлять проверку поля Referer с целью отклонения запросов на определенные ресурсы, если ссылки на ресурсы находились на страницах, не контролируемых сервером. Например, предположим, что ссылка на встроенное изображение onlymine.gif, изначально принадлежащее ресурсу А, было скопировано в другой документ, В. Теперь, если браузер попытается отобразить документ В, он должен сформировать запрос на ресурс onlymine.gif и включить в запрос заголовок Referer с нолем значения, соответствующим ресурсу В. Сервер может отказать в обработке запроса, поскольку поле Referer не содержит А.

•      User-Agent. Поле User-Agent может быть использовано для включения информации о версии программного обеспечения браузера, версии операционной системы компьютера клиента и, возможно, каких-либо сведений об аппаратной конфигурации. Вот примеры заголовков User-Agent:

User-Agent: Mozilla/4.03 (Macintosh; I; 68K, Nav) User-Agent: Mozilla/4.04 [en] C-WorldNet (Win95; I)

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

ЗАГОЛОВКИ ОТВЕТА

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

В НТТР/1.0 определены три заголовка ответа:

•          Location. Заголовок Location иснользуется для направления запроса в место расположения ресурса и полезеп при переадресации ответов (см. раздел 6.2.4). Заголовок Location имеет следующий синтаксис:

Location: http://www.foo.com/level1/twosdown/Location.html

Поскольку в ответ на запрос могут быть выбрапы различные варианты ресурса, заголовок Location предоставляет возможность идентификации местонахождения выбранного варианта. Если группа ресурсов реплицировапа на нескольких зеркальных сайтах, заголовок Location может быть использован для указання на пужпый сайт, с которого клиент должен получить ресурс. Если в результате выполпепия запроса (например, POST) был создай повый ресурс, заголовок Location идентифицирует созданный ресурс.

•          Server. Заголовок ответа Server аналогичен заголовку запроса User-Agent. Заголовок Server песет информацию о версии программного обеспечения исходного сервера н любую другую информацию, связанную с его конфигурацией. Вот несколько типичных примеров заголовка Server:

Server: Apache/1.2.6 Red Hat Server: Netscape-Enterprise/3.5.1

Server: Apache/1.x.y mod_perl mod_ssl mod_foo mod_bar

Зпачепие, указанное в заголовке Server, полезпо для выявления и решения проблем в ответе, а также для сбора статистической информации, позволяющей определить наиболее популярные версии серверов. Минусом здесь является то, что, данная информация облегчает атаку на сервер. Подобпо заголовку User-Agent, заголовок Server не является обязательным и может не включаться в ответы.

•          WWW-Authenticate. Заголовок WWW-Authenticate используется для ука- запия клиенту, что ресурс требует аутентификации. Клиенту возвращается ответ 401 Unauthorized, и он может повторно обратиться с запросом, указав соответствующие данные в заголовке Authorization. Например, сервер может отправить такой ответ:

WWW-Authenticate: Basic realm="ChaseChem"

и клиенту следует включить в свой запрос необходимую аутсптификациоп- пую информацию, как разъяснялось раиее в этом разделе.

ЗАГОЛОВКИ СОДЕРЖИМОГО

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

В НТТР/1.0 определено шесть заголовков содержимого:

•          Allow. Заголовок содержимого Allow используется для указания списка доступных методов, которые могут быть применены к ресурсу. Он может использоваться и в запросах, и в ответах. Например, метод PUT может содержать заголовок AIlow в запросе, перечисляющий методы, которые могут применяться к ресурсу. При получении запроса на применение некорректного метода к ресурсу исходный сервер отправит в ответ заголовок Allow со списком допустимых для этого ресурса методов. Заголовок Allow также может быть применен в успешном ответе для указания полного списка приемлемых для данного ресурса методов.

Рассмотрим пример использования заголовка содержимого в сообщепин-за- иросе

PUT /foo.html НТТР/1.0 Allow: HEAD, GET, PUT

Запрос информирует сервер, где будет сохранен ресурс /foo.html, что к этому ресурсу разрешается применять методы HEAD, GET и PUT. Другие методы запроса, которые могут попытаться применить клиенты, не должны допускаться исходным сервером.

•          Content-Type. Заголовок Content-Type указывает на тип представления тела содержимого, например, image/gif, text/html или application/x-javascript. Метод POST может включать форму со следующим заголовком Content- Type:

POST /chat/chatroom.cgi НТТР/1.0 User-Agent: Mozilla/3.0C

Content-Type: application/x-www-form-urlencoded

Различные типы представления содержимого, используемые в Content-Type, должиы быть зарегистрированы организацией IANA.

•          Content-Encoding. Заголовок Content-Encoding указывает, как было модифицировано представление ресурса, и как оно может быть декодировано в формат, указанный в заголовке содержимого Content-Type. Кодирование содержимого выполняется над документами для преобразования их без потерь информации. Типичным примером такого преобразования является

сжатие. Чтобы преобразовать ответ обратно к его исходному виду, получатель должен располагать соответствующей технологией декодирования. Сообщение, содержимое которого было сжато с использованием gzip, может содержать заголовок

Content-Encoding: x-gzip

По мере регистрации IANA могут быть определены новые типы содержания, согласно документу RFC 1590.

•      Content-Length. Заголовок Content-Length указывает на длину тела содержимого в байтах. Длииа содержимого важна для обеспечения полной доставки отправленного тела содержимого получателю. Значение Content-Length может использоваться в качестве валидатора для сравнения кэшированпого содержания с текущей его версией. Без заголовка Content-Length в запросе клиенту пришлось бы закрывать соединение, чтобы указать на завершение передачи запроса. В разделе 6.2.2 мы рассмотрели пример запроса POST, использующего заголовок Content-Length. Если ответ генерируется динамически, весь ответ должен быть сформирован до того, как станет известна длина содержимого. Поскольку длииа содержимого Content-Length является зпачепи- ем поля заголовка и должна быть вставлена в сообщение-ответ перед телом ответа, время ожидания на стороне получателя увеличивается. Обычно для динамических ответов заголовок Content-Length опускается. Если динамически сгенерированный ответ был буферизирован перед отправкой, длина содержимого может быть известна. В НТТР/1.0 в качестве индикатора копца содержимого используется закрытие соединения.

•      Expires. Заголовок Expires предоставляет отправителю возможность заявить, что содержимое должпо считаться устаревшим после истечения времени, указанного в заголовке. Клиент не должен кэшировать ответ позже даты, заданной в заголовке Expires. Разница между хранением ресурса в кэше и кэшированием весьма существенна. Ответ может храниться (т.е. удерживаться) в кэше и по истечении срока хранения, но он не может быть возвращен как ответ без проверки его актуальности на исходным сервере. Expires является заголовком содержимого, а не заголовком ответа но той причине, что истечение времени храпепия ассоциируется с ресурсом, а не с сообщением. Сервер может отправить сообщение

НТТР/1.0 200 0K

Server: Microsoft-IIS/4.0

Date: Mon, 04 Dec 2000 18:16:45 GMT

Expires: Tue, 05 Dec 2000 18:16:45 GMT

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

•      Last-Modified. Заголовок Last-Modified указывает время последнего изменения ресурса. Если ресурсом является статический файл, то этим значением может быть дата последнего изменения ресурса в файловой системе. Динамически генерируемый ресурс может иметь время Last-Modified, совпадающее со временем создания сообщения-ответа сервером. Фактически время Last- Modified никогда не может быть большим, чем время создания сообщения. Протокол не определяет правила для вычисления времени истечения срока храпения. Заголовок Last-Modified в ответе подсказывает получателю сравнить это значение со зпачепием Last-Modified кэшированной версии, чтобы проверить, не устарел ли кэшированный ресурс. Наличие заголовка Last-

Modified трактуется некоторыми кэшами в НТТР/1.0 как указание, что содержимое не было сгенерировано динамически, поскольку заголовок Last-Modified для динамически сформированного содержимого не имеет особого смысла. В главе 7 (раздел 7.3.2) мы более подробно обсудим назначение заголовков, связанных с кэшированием.

Сервер может отправить сообщение, подобное следующему: НТТР/1.0 200 0K

Date: Sun, 21 May 2000 08:09:12 GMT Last-Modified: Sun, 21 May 2000 07:00:25 GMT

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