HTTP Header Linkingmnot@pobox.comhttp://www.mnot.net/This specification clarifies the status of the Link HTTP header and introduces
the complimentary Profile and Link-Template HTTP headers.A means of indicating the relationships between documents on the Web has been
available for some time in HTML, and was considered as a HTTP
header in , but removed from ,
due to a lack of implementation experience.There have since surfaced many cases where a means of including this
information in HTTP headers has proved useful. However, because it was removed,
the status of the Link header is unclear, leading some to consider
minting new application-specific HTTP headers instead of reusing it.Additionally, the complementary "profile" mechanism -- which is often
used to disambiguate link relationship types -- is not available as a
HTTP header.This specification seeks to address these shortcomings. It also introduces
a new header, Link-Template, that allows the structure of links to be
described.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14, , as
scoped to those conformance targets.This specification uses the Augmented Backus-Naur Form (ABNF)
notation of , and explicitly includes the following
rules from it: quoted-string, token, SP (space), ALPHA (letters),
DIGIT (decimal digit). Additionally, the following rules are included from
: URI-Reference, reserved, unreserved.The Link entity-header field provides a means for describing a
relationship between two resources, generally between the requested
resource and some other resource. An entity MAY include multiple Link
values. Links at the metainformation level typically indicate
relationships like hierarchical structure and navigation paths. The
Link field is semantically equivalent to the <LINK> element in
HTML.Relationship values are case-insensitive and MAY be extended within
the constraints of the sgml-name syntax. The title parameter MAY be
used to label the destination of a link such that it can be used as
identification within a human-readable menu. The anchor parameter MAY
be used to indicate a source anchor other than the entire current
resource, such as a fragment of this resource or a third resource.Examples of usage include:The first example indicates that chapter2 is previous to this
resource in a logical navigation path. The second indicates that the
person responsible for making the resource available is identified by
the given e-mail address.The Profile entity-header field provides a means to indicate the meta
data profile of the entity. Commonly, it is used to disambiguate the meaning
of relationships in links.Note that this URI MAY be used as either an identifier (e.g., to uniquely
identify links, without dereferencing the URI), or as a link that is intended
to be dereferenced.The Profile field is semantically equivalent to the profile attribute of the
HEAD element in HTML . Note, however,
that its use is not limited to HTML entities.For example:The Link-Template entity-header field provides a means for describing
the structure of a link between two resources, so that new links can be
generated.It does so through by allowing brace ("{}") -delimited strings
to be interposed throughout a URI reference. These correspond to variables
which, after being replaced with content in a relation-specified manner, are
semantically equivalent to the corresponding Link header.For example,This link indicates that the "home" link relation can be constructed if the
userid variable is known; if it were known to be "bob", this header would be
considered equivalent toThis specification does not define when or how template variables are
interposed into link templates. Link relations that wish to allow templating
SHOULD specify such details.This specification does not define the correct behaviour in the face of a
conflict between a Link-Template header and a Link header with the same
relation. Link relations allowing templating SHOULD specify their relative
precedence.Applications SHOULD NOT use link relations that do not explicitly allow
such templating in the Link-Template header.This specification requires registration of two Message Header Fields for HTTP
. Note that "Link" is already present in the registry; this registration only
updates its specification document.The content of both the Link and Profile headers are not secure, private
or integrity-guaranteed, and due caution should be excercised when using them.
Applications that take advantage of these mechanisms should consider the
attack vectors opened by automatically following, trusting, or otherwise using
links gathered from HTTP headers.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Registration Procedures for Message Header FieldsThis specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. HTML 4.01 SpecificationHypertext Transfer Protocol -- HTTP/1.1University of California, Irvine, Department of Information and Computer ScienceIrvineCA92717-3425US+1 714 824 4056fielding@ics.uci.eduMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 258 8682jg@w3.orgDigital Equipment Corporation, Western Research Laboratory250 University AvenuePalo AltoCA94301USmogul@wrl.dec.comMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 258 8682frystyk@w3.orgMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 258 8682timbl@w3.orgThe Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".This specification lifts the definition of the Link header
from RFC2068; credit for it belongs entirely to the authors of and contributors
to that document.The semantics and much of the syntax of the Profile header was defined by
HTML 4.01; credit for them belongs to the authors of and contributors to that
document.Joe Gregorio, Marc Hadley and David Orchard contributed to the design of
the Link-Template mechanism.