7. Entity
Entity-Header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Transfer-Encoding | Content-Type | Derived-From | Expires | Last-Modified | Link | Location | Title | URI-header | Version | extension-header extension-header = HTTP-headerEach entity header field is explained in the subsections below. Other header fields are allowed but cannot be assumed to be recognizable by the recipient. Unknown header fields should be ignored by the recipient and forwarded by proxies.
Note
It has been proposed that any HTML metainformation element (allowed within the <HEAD> element of a document) be a valid candidate for an HTTP entity header. This document defines two header fields, Link and Title, which are both examples of this. Base will be used in future versions of HTTP.
Allow = "Allow" ":" 1#methodExample of use:
Allow: GET, HEAD, PUTThis does not prevent a client from trying other methods. However, it is recommended that the indications given by this field be followed. This field has no default value; if left undefined, the set of allowed methods is defined by the origin server at the time of each request.
If a response passes through a proxy which does not understand one or more of the methods indicated in the Allow header, the proxy must not modify the Allow header; the user agent may have other means of communicating with the origin server.
Content-Encoding = "Content-Encoding" ":" encoding-mechanismEncoding mechanisms are defined in Section 8.4. An example of its use is
Content-Encoding: gzipThe Content-Encoding is a characteristic of the resource identified by the Request-URI. Typically, the resource is stored with this encoding and is only decoded before rendering or analogous usage.
Content-Language = "Content-Language" ":" 1#language-tagLanguage tags are defined in Section 8.2. The primary purpose of Content-Language is to allow a selective consumer to identify and differentiate resources according to the consumer's own preferred language. Thus, if the body content is intended only for a Danish audience, the appropriate field is
Content-Language: dkIf no Content-Language is specified, the default is that the content is intended for all language audiences. This may mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.
Multiple languages may be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented simultaneously in the original Maori and English versions, would call for
Content-Language: mi, enHowever, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English audience. In this case, the Content-Language should only include "en".
Content-Language may be applied to any media type -- it should not be considered limited to textual documents.
Content-Length = "Content-Length" ":" 1*DIGITAn example is
Content-Length: 3495Although it is not required, applications are strongly encouraged to use this field to indicate the size of the Entity-Body to be transferred, regardless of the media type of the entity.
Any Content-Length greater than or equal to zero is a valid value. Section 7.2.2 describes how to determine the length of an Entity-Body if a Content-Length is not given.
Note
The meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it should be used whenever the entity's length can be determined prior to being transferred.
Content-Transfer-Encoding = "Content-Transfer-Encoding" ":" transfer-encodingTransfer encodings are defined in Section 8.5. Because all HTTP transactions take place on an 8-bit clean connection, the default Content-Transfer-Encoding for all messages is binary. However, HTTP may be used to transfer MIME messages which already have a defined CTE. An example is:
Content-Transfer-Encoding: quoted-printableMany older HTTP/1.0 applications do not understand the Content-Transfer-Encoding header. However, since it may appear in any MIME message (i.e. entities retrieved via a gateway to a MIME-conformant protocol), future HTTP/1.0 applications are required to understand it upon receipt. Gateways are the only HTTP applications that would generate a CTE.
Content-Type = "Content-Type" ":" media-typeMedia types are defined in Section 8.1. An example of the field is
Content-Type: text/html; charset=ISO-8859-4The Content-Type header field has no default value. Further discussion of methods for identifying the media type of an entity is provided in Section 7.2.1.
Derived-From = "Derived-From" ":" version-tagAn example use of the field is:
Derived-From: 2.1.1A longer example of version control is included in Appendix C. The Derived-From field is required for PUT requests if the entity being put was previously retrieved from the same URI and a Version header was included with the entity when it was last retrieved.
Expires = "Expires" ":" HTTP-dateAn example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMTThe Expires field has no default value. If the date given is equal to or earlier than the value of the Date header, the recipient must not cache the enclosed entity. If a resource is dynamic by nature, as is the case with many data-producing processes, copies of that resource should be given an appropriate Expires value which reflects that dynamism.
The Expires field cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated.
Note
Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. In particular, recipients may wish to recognize a delta-seconds value (any decimal integer) as representing the number of seconds after receipt of the message that its contents should be considered expired. Likewise, a value of zero (0) or an invalid date format may be considered equivalent to an "expires immediately." Although these values are not legitimate for HTTP/1.0, a robust implementation is always desirable.
Last-Modified = "Last-Modified" ":" HTTP-dateAn example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMTThe exact meaning of this header field depends on the implementation of the sender and the nature of the original resource. For files, it may be just the file system last-mod date. For entities with dynamically included parts, it may be the most recent of the set of last-mod dates of its component parts. For database gateways, it may be the last-update timestamp of the record. For virtual objects, it may be the last time the internal state changed. In any case, the recipient should only know (and care) about the result -- whatever gets stuck in the Last-Modified field -- and not worry about how that result was obtained.
<LINK> element in HTML [4].
Link = "Link" ":" 1#("<" URI ">"
[ ";" "rel" "=" relation ]
[ ";" "rev" "=" relation ]
[ ";" "title" "=" quoted-string ] )
relation = sgml-name
sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
Relation values are not case-sensitive and may be extended within the constraints of the sgmlname syntax. There are no predefined link relationship values for HTTP/1.0. 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. Examples of usage include:
Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"The first example indicates that the entity is previous to chapter2 in a logical navigation path. The second indicates that the publisher of the resource is identified by the given e-mail address.
Location = "Location" ":" URIAn example is
Location: http://info.cern.ch/hypertext/WWW/NewLocation.html
Title = "Title" ":" *textAn example of the field is
Title: Hypertext Transfer Protocol -- HTTP/1.0This field is to be considered isomorphic with the <TITLE> element in HTML [4].
URI-header = "URI" ":" 1#( "<" URI ">" [ ";" vary ] ) vary = "vary" "=" <"> 1#vary-dimension <"> vary-dimension = "type" | "language" | "version" | "encoding" | "charset" | "user-agent" | extension-vary extension-vary = tokenAny URI specified in this field can be either absolute or relative to the URI given in the RequestLine. The URI-header improves upon the Location header field described in Section 7.1.11. For backwards compatibility with older clients, servers are encouraged to include both header fields in 301 and 302 responses.
The URI-header may also be used by a client performing a POST request to suggest a URI for the new entity. Whether or not the suggested URI is used is entirely up to the server to decide. In any case, the server's response must include the actual URI(s) of the new resource if one is successfully created (status 201).
If a URI refers to a set of variants, then the dimensions of that variance must be given with a vary parameter. One example is:
URI: <http://info.cern.ch/hypertext/WWW/TheProject.multi>;
vary="type,language"
which indicates that the URI covers a group of entities that vary in media type and natural language. A request for that URI will result in a response that depends upon the client's request headers for Accept and Accept-Language. Similar dimensions exist for the Accept-Encoding, Accept-Charset, Version, and User-Agent header fields, as demonstrated in the following example.
URI: <TheProject.ps>;vary="encoding,version",
<TheProject.html>;vary="user-agent,charset,version"
The vary parameter has an important effect on cache management, particularly for caching proxies which service a diverse set of user agents. Since the response to one user agent may differ from the response to a second user agent if the two agents have differing request profiles, a caching proxy must keep track of the content metainformation for resources with varying dimensions. Thus, the vary parameter tells the caching proxy what entity headers must be part of the key for caching that URI. When the caching proxy gets a request for that URI, it must forward the request toward the origin server if the request profile includes a variant dimension that has not already been cached.
Version = "Version" ":" version-tag version-tag = token | quoted-stringExamples of the Version field include:
Version: 2.1.2 Version: "Fred 19950116-12:26:48" Version: 2.5a4-omega7The version tag should be considered opaque to all parties but the origin server. A user agent can request a particular version of an entity by including its tag in a Version header as part of the request. Similarly, a user agent may suggest a value for the version of an entity transferred via a PUT or POST request. However, only the origin server can reliably assign or increment the version tag of an entity.
Generated with CERN WebMaker