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.)
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"
Example of use:
Allow: GET HEAD PUT
As "Allow" but lists those requests
which anyone may use. If omitted,
the default is "GET" only.
Example of use:
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.
Extra non-MIME types
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.
Multipart types
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.
Multipart/related
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 [proposed]
"cid:" URI type may be used to refer
to them by content-identifier.
Multipart/mixed
This may be used to simply transfer
an unrelated unstructured set of
objects. Examples are a picture
with audio commentary, etc.
Multipart/parallel
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.
Examples
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.
Example
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.
Examples
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.
Last modified: May 3, 1994
Site Hosting: Bronco