Метод link

Метод LINK устанавливает одну или более связей между ресурсами, идентифицированными Request-URI, и другими существующими ресурсами. Отличие между LINK и другими методами, допускающими установление связей между ресурсами, заключается в том, что метод LINK не позволяет послать в запросе любое тело сообщения и не вызывает непосредственно создания новых ресурсов. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют LINK, должны объявить кэшированные отклики непригодными.

Определения дополнительных полей заголовка Поле Alternates

Поле заголовка отклика Alternates было предложено в качестве средства исходного сервера для информирования клиента о других доступных представлениях запрошенного ресурса. При этом выдается информация об их специфических атрибутах, и все это образует более надежное основание агенту пользователя для выбора представления, которое лучше соответствует желаниям пользователя. Поле заголовка Alternates является ортогональным по отношению к полю заголовка Vary, но вместе с тем они могут сосуществовать в сообщении без последствий для интерпретации отклика или доступных представлений. Ожидается, что поле Alternates предоставит заметное улучшение по сравнению с согласованием под управлением сервера, предлагаемым полем Vary для ресурсов, которые варьируются в общих пределах подобно типу и языку.

Поле Content-Version

Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, это позволяет группе людей вести разработку в интерактивном режиме.

Content-Version = "Content-Version" ":" quotedstring.

Примеры использования поля Content-Version:

Content-Version: "1.3.1" Content-Version: "Fred 1895011511:25:39" Content-Version: "2.6b4omega8"

Поле Derived-From

Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем. Это поле применяется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются параллельно многими субъектами.

Derived-From = "Derived-From" ":" quotedstring.

Пример использования поля:

Derived-From: "1.1.1".

Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался.

Поле Link

Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML [7.5].

Link = "Link" ":"#("<" URI ">" *(";" linkparam) linkparam = (("rel" "=" relationship ) | ("rev" "=" relationship) | ( 'title" "=" quotedstring ) | ( "anchor" "=" <"> URI <"> ) | (linkextension )) linkextension = token ["=" (token | quotedstring )] Relationship = sgmlname | ( <"> sgmlname *( SP sgmlname) <"> ) sgmlname = ALPHA *( ALPHA | DIGIT | "." | "")

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

Link: ; rel="Previous" Link: ; rev="Made"; title="Tim BernersLee"

Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй демонстрирует, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты.

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

Вопросы:

1 Что такое HTTP протокол? 2 Для чего используется HTTP протокол 3 Характеристики HTTP протокола 4 HTTP протокол работает по принципу клиент-сервер 5 История HTTP: стандарты HTTP протокола 6 Клиенты HTTP протокола 7 Серверы HTTP протокола 8 Требования HTTP протокола 9 Структура HTTP протокола 10 Терминология HTTP протокола 11 Параметры HTTP протокола 12 Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ 13 Методы в HTTP протоколе 14 Как происходит соединение по HTTP протоколу 15 Обсуждение содержимого в HTTP протоколе 16 Коды состояния в HTTP протоколе 17 Поля заголовка HTTP сообщения 18 Кэширование HTTP протокола 19 Безопасность HTTP протокола