The header fields given with or in relation to objects in HTTP are as follows. All are optional. These headers specify metainformation: that is, information about the object, not the information which is contained in the object.
There is no reason for limiting these fields to HTTP use, as any other system which requires metainformation is encouraged to use them.
The order of header lines withing the HTTP header has no significance. However, those fields which are not MIME fields should occur before the MIME fields, so that the MIME fields and following form a valid MIME document. This is not mandatory.
Any header fields which are not understood should be ignored.
(TBS in more detail.)
Allowed
Public
Content-Length
Content-Type
Content-Transfer-Encoding
Content-Encoding
Date
Expires
Last-Modified
Message-Id
URI
Version
Derived-From
Content-Language
Cost
Link
Title
Lists the set of requests which the requesting user is allowed to issue for this URL. If this header line is omitted, the default allowed methods are "GET HEAD"
Allow: GET HEAD PUT
As "Allow" but lists those requests which anyone may use. If omitted, the default is "GET" only.
Public: GET HEAD TEXTSEARCH
Implies that the body is binary and should be read directly from the communications link, without parsing lines, etc. When the data is part of the request, prevents the escaping and de-escaping of the termination sequence .
@@@ This should be part of the MIME header, as it applies to any binary encoded part. Note HTML is the first internet protocol to allow MIME "binary" encoding. In MIME, the use of Content-Length is currently allowed only for external messages.
As defined in MIME , except where noted here.
It is reasonable to put strict limits on transfer formats for mail, where there is no guarantee that the receiver will understand a weird format. However, in HTTP one knows that the receiver will be able to receive it because it will have been sent in the Accept: field . There is therefore a lot to be gained from a very complete registry of well-defined types for HTTP which may nevertheless not be recommended for mail. In this case, the content-type list for HTTP may be a superset of the MIME list.
The x- convention for experimental types is of course still available as well.
MIME provides for a number of "multipart" types. These are encapsulations of several body parts in the one message. In HTTP, Multipart types may be returned on the condition that the client has indicated acceptability (using Accept: )of the multipart type and also of the content types of each consitutent body part.
The body parts ( unlike in MIME ) MAY contain HTTP metainformation header fields which ARE significant.
This is normally used in mail to send different content-type variants when the receiver's capabilities are not known. This is not the case with HTTP. Multipart/alternate may however be used to provide meta information of many instances of an object, in the case of a indirection response . This allows, for example, pointers to be returned by a name server to a set of instances of an object.
This is the type to be used when the first body part contains references to other parts which the server wishes to send at the same time. For example, the first part could be an HTML document, and the included bodyparts could be the inline images mentioned within the text.
The body parts may have URI: fields if the body parts have URIs, and so they may be referred to by these URIs in the body-parts. If the body-parts are transient (as in speech insertions in mail messages) then the [propsed] "cid:" URI type may be used to refer to them by content-identifier.
This may be used to simply transfer an unrelated unstructured set of objects. Examples are a picture with audio commentary, etc.
This may be used as in MIME to indicate simultaneous presentation. [It is the author's belief that this is a trivial case of a compound presentation which in general should be described by a script which would be the first bodypart of a multipart/related document].
As in MIME. Some profiling and/or extension may be necessary, TBS. (Compression is not treated as transfer encoding by MIME).
Specifies the encoding mechamism used. Currently in use only
x-compress and x-gzip.
Creation date of object. (or last modified, and separately have a Created: field?) Format as in RFC850 but GMT MUST BE USED.
Gives the date after which the information given ceases to be valid and should be retrieved again. This allows control of caching mechanisms, and also allows for the periodic refreshing of displays of volatile data. Format as for Date:. This does NOT imply that the original object will cease to exist.
Last time object was modified, i.e. the date of this version if the document is a "living document". Format as for Date:.
A unique identifier for the message. As in RFC850 , except that the unlimited lifetime of HTTP objects requires that the Message-ID be unique in all time, not just in two years.
A document may only have one Message-ID.
No two documents, even if different versions of the same live document, may have the same Message-id.
Note: Unlike the URI field, this does not fgive a way of accessing the document, so the Message-Id cannot be used to refer to the document. In the case of NNTP articles, the message-id may in fact be used within the URI for retrieval using NNTP.
This gives a URI with which the object may be found. There is no guarantee that the object can be retrieved using the URI specified. However, it is guaranteed that if an object is successfully retrieved using that URI it will be to a certain given degree the same object as this one.
If the URI is used to refer to a set of variants, then the dimensiosn in which the variants may differ must be given with the "vary" parameter:
Syntax URI: <uri> [ ; vary = dimension [ , dimension ]* ] dimension content-type | language | version
If no "vary" parameters are given, then the URI may not return anything other than the same bit stream as this object.
Multiple occurencies of this field give alternative access names or addresses for the object.
URI: http://www.w3.org/pub/www/doc/url6.multi; vary=content-type
This indicates that retrieval given the URI will return the same document, never an updated version, but optionally in a different rendition.
URI: http://www.w3.org/pub/www/doc/url.multi; vary=content-type, language, version
This indicates that the URI will return the smae document, possibly in a different rendition, possibly updated, and without excluding the provision of translations into different languages.URI: http://www.w3.org/pub/www/doc/url6.ps vary=content-typeThis indicates that accessing the URI in question will return exactly the same bitstream.
This is a string defining the version of an evolving object. Its format is currently undefined , and so it should be treated as opaque to the reader, defined by the informatiuon provider. The version field is used to indicate evolution along a single path of a partucular work. It is NOT used to indicate derived works (use a link), translations , or renditions in different representations .
Note: It would be useful to have sufficient semantics to be able to deduce whether one version predated or postdated another. However, it may also be useful to be able to insert a particular local code management system's own version stamp in this field. Typically, publishers will have quite complex version information containing hidden local semantics, giving value to the idea of this field being opaque to other readers ofthe document.
When an editied object is resubmitted using PUT for example, this field gives the value of the Version . This typically allows a server to check for example that two concurrent modifications by different parties will not be lost, and for example to use established version management techniques to merge both modifications.
The language code is the ISO code for the language in which the document is written. If the language is not known, this field should be omitted of course .
The language code is an ISO 3316 language code with an optional ISO639 country code to specify a national variant.
Content-Language: en_UK
means that the content of the message is in British English, while
Content-Language: en
means that the language is English in one of its forms. (@@ If a document is in more than one language, for example requires both Greek Latin and French to be understood, should this be representable?)
See also: Accept-Language.
The cost of retrieving the object is given. This is the cost of access of a copyright work, with a specification of the payment system accepted. Format to be specified. Currently refers to an unspecified charging scheme to be agreed out of band between parties.
Note that ISO 4217 provides a standard for desription of currency codes, but that one can imagine payment methods which have their own currency (Club Med iI believe uses cloured beads).
Note. It is proposed that any HTML metainformation element (allowed withing the HEAD as opposed to BODY element of the document) be a valid candidate for an HTTP object header. LINK is one example, TITLE another. One suggestion was that the isomorphism should be realized by prepending "WWW-" to the HTML element name to make the HTTP header name, and the HTML attributes imply identically named semicolon-separated MIME-style header parameters. It is open to discussion whether the "WWW-" should be inserted or not.
This is semantically equivalent to the LINK element in an HTML document which should be consulted for a full explanation.
WWW-Link: href="http://www.w3.org/a/b/c"; rel="includes" WWW-Link: href="mailto:timbl@info.cern.ch"; rev=made
The first example indicates that this object includes the specified /a/b/c object. The second indicates that the author of the object is identified by the given mail address.
The title of the document. Not part of the document. Syntax is as for the Subject field in RFC822. The Title field differs from the Subject field in that the title is defined by the author of a document, but the Subject field is defined by the originator.
WWW note: Isomorphic with the <TITLE> element in HTML.