These header lines are sent by the
client in a HTTP protocol transaction.
All lines are RFC822 format headers.
The list of headers is terminated
by an empty line.
In Internet mail format, this gives
the name of the requesting user.
This field may be used for logging
purposes and an insecure form of
access protection. The interpretation
of this field is that the request
is being performed on behalf of the
person given, who accepts responsability
for the method performed.
The Internet mail address in this
field does not have to correspond
to the internet host which issued
the request. (For example, when a
request is passed through a gateway,
then the original issuer's address
should be used).
The mail address should, if possible,
be a valid mail address, whether
or not it is in fact an internet
mail address or the internet mail
representation of an address on some
other mail system.
This field contains a semicolon-separated
list of representation schemes (
Content-Type metainformation values)
which will be accepted in the response
to this request.
The set given may of course vary
from request to request from the
same user.
This field may be wrapped onto several
lines according to RCFC822, and also
more than one occurence of the field
is allowed with the signifiance being
the same as if all the entries has
been in one field. The format of
each entry in the list is (/ meaning
"or")
<field> = Accept: <entry> *[ , <entry> ]
<entry> = <content type> *[ ; <param> ]
<param> = <attr> = <float>
<attr> = q / mxs / mxb
<float> = <ANSI-C floating point text represntation>
See the appendix on the negotiation
algorithm as a function and penalty
model. Note that a semicolon has
a higher precedence than a comma
in this syntax, to conform to MIME
use.
If no Accept: field is present, then
it is assumed that text/plain and
text/html are accepted.
Example
Accept: text/plain, text/html
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
Wildcards
In order to save time, and also allow
clients to receive content types
of which they may not be aware, an
asterisk "*" may be used in place
of either the second half of the
content-type value, or both halves.
This only applies to the Accept:
filed, and not to the content-type
field of course.
Example
Accept: *.*, q=0.1
Accept: audio/*, q=0.2
Accept: audio/basic q=1
may be interpreted as "if you have
basic audio, send it; otherwise send
me some other audio, or failing that,
just give me what you've got."
Type parameters
Parameters on the content type are
extremely useful for describing resolutions,
colour depths, etc. They will allow
a client to specify in the Accept:
field the resolution of its device.
This may allow the server to economise
greatly on transmission time by reducing
the resultion of an image, for example,
and enable a more appropriate custom-designed
black and white image to be selected
rathther than giving the client a
color image to convert into monochrome.
These parameters are to be specified
when types are registered.. @@ TBS.
Sugestions include the following.
Please feed back any references to
existing improved abreviations for
these:
- dpi
- dots per inch: pixels per inch
[cm?!]
- pxmax
- maximum width in pixels (image
or video)
- pymax
- maximum height in pixels
- bits
- bits per sample (sound) or pixels
(graphics)
- mchrome
- greyscale or black and white
(no value)
- sps
- samples (sound) or frames (video)
per second
- length
- total size of object in bytes
[bits?]
Similar to Accept, but lists the
Content-Encoding types which are
acceptable in the response.
<field> = Accept-Encoding: <entry> *[ , <entry> ]
<entry> = <content transfer encoding> *[ , <param> ]
Example
Accept-Encoding: x-compress; x-zip
Similar to Accept, but lists the
Language values which are preferable
in the response. A response in an
unspecifies language is not illegal.
See also: Language .
Language coding TBS. (ISO standard xxxx.)
This line if present gives the software
program used by the original client.
This is for statistical purposes
and the tracing of protocol violations.
It should be included. The first
white space delimited word must be
the software product name, with an
optional slash and version designator.
Other products which form part of
the user agent may be put as separate
words.
<field> = User-Agent: <product>+
<product> = <word> [/<version>]
<version> = <word>
Example:
UserAgent: LII-Cello/1.0 libwww/2.5
This optional header field allows
the client to specify, for the server's
benefit, the address ( URI ) of the
document (or element within the
document) from which the URI in the
request was obtained.
This allows a server to generate
lists of back-links to documents,
for interest, logging, etc. It allows
bad links to be traced for maintenance.
If a partial URI is given, then it
should be parsed relative to the
URI of the object of the request.
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If this line is present it contains
authorization information. The format
is To Be Specified (TBS). The format
of this field is in extensible form.
The first word is a specification
of the authorisation system in use.
Basic
Specification for
current one implemented by AL Sep 1993.
PGP/PEM Encryption
People at NCSA are designing a PGP/PEM based
protection system.
User/Password scheme
Authorization: user fred:mypassword
The scheme name is "user". The
second word is a user name (typically
derived from a USER environment variable
or prompted for), with an optional
password separated by a colon (as
in the URL syntax for FTP). Without
a password, this povides very low
level security. With the password,
it provides a low-level security
as used by unmodified FTP, Telnet,
etc.
Kerberos
Authorization: kerberos kerberosauthenticationsparameters
The format of the kerberosauthenticationsparameters
is to be specified.
This line if present contains account
information for the costs of the
application of the method requested.
The format is TBS. The format of
this field must be in extensible
form. The first word starts with
a specification of the namespace
in which the account is . (This is
similar to extensible URL definition.)
No namespaces are currently defined.
Namespaces will be registered with
the registration authority .
The format of the rest of the line
is a function of the charging system,
but it is recommended that this include
a maximum cost whose payment is authorized
by the client for this transaction,
and a cost unit.
This request header is used with GET method to make it conditional:
if the requested document has not changed since the time specified
in this field the document will not be sent, but instead a
Not Modified 304
reply.
Format of this field is the same as for
Date:.
Syntax is the same as for other multiple-value fields in HTTP, like
the Accept: field, namely, a comma-separated list
of entries, for which the optional parameters are separated by
semicolons.
Pragma directives should be understood by servers to which they are
relevant, e.g. a proxy server; currently only one pragma is defined:
-
no-cache
- When present the proxy should not return a document from the
cache even though it has not expired, but it should always request the
document from the actual server.
Pragmas should be passed through by proxies even though they might
have significance to the proxy itself. This is necessary in cases
when the request has to go through many proxies, and the pragma should
affect all of them.
Last modified: May 3, 1994
Site Hosting: Bronco