RFC 2068                        HTTP/1.1                    January 1997


19.6.2.4 Link

   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  element in
   HTML.[5]

          Link           = "Link" ":" #("<" URI ">" *( ";" link-param )

          link-param     = ( ( "rel" "=" relationship )
                             | ( "rev" "=" relationship )
                             | ( "title" "=" quoted-string )
                             | ( "anchor" "=" <"> URI <"> )
                             | ( link-extension ) )

          link-extension = token [ "=" ( token | quoted-string ) ]

          relationship   = sgml-name
                         | ( <"> sgml-name *( SP sgml-name) <"> )

          sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

   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:

       Link: ; rel="Previous"

       Link: ; rev="Made"; title="Tim Berners-Lee"

   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.

19.6.2.5 URI

   The URI header field has, in past versions of this specification,
   been used as a combination of the existing Location, Content-
   Location, and Vary header fields as well as the future Alternates



Fielding, et. al.           Standards Track                   [Page 159]

RFC 2068                        HTTP/1.1                    January 1997


   field (above). Its primary purpose has been to include a list of
   additional URIs for the resource, including names and mirror
   locations. However, it has become clear that the combination of many
   different functions within this single field has been a barrier to
   consistently and correctly implementing any of those functions.
   Furthermore, we believe that the identification of names and mirror
   locations would be better performed via the Link header field. The
   URI header field is therefore deprecated in favor of those other
   fields.

          URI-header    = "URI" ":" 1#( "<" URI ">" )

19.7 Compatibility with Previous Versions

   It is beyond the scope of a protocol specification to mandate
   compliance with previous versions. HTTP/1.1 was deliberately
   designed, however, to make supporting previous versions easy. It is
   worth noting that at the time of composing this specification, we
   would expect commercial HTTP/1.1 servers to:

  o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
     requests;

  o  understand any valid request in the format of HTTP/0.9, 1.0, or
     1.1;

  o  respond appropriately with a message in the same major version used
     by the client.

   And we would expect HTTP/1.1 clients to:

  o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
     responses;

  o  understand any valid response in the format of HTTP/0.9, 1.0, or
     1.1.

   For most implementations of HTTP/1.0, each connection is established
   by the client prior to the request and closed by the server after
   sending the response. A few implementations implement the Keep-Alive
   version of persistent connections described in section 19.7.1.1.










Fielding, et. al.           Standards Track                   [Page 160]