| Advanced Java Services | HTTP 1.0 Headernames |
|
Die folgenden Tabelle beschränkt sich auf die Headernamen des ersten HTTP-Protokolls 1.0 .
Sie stammen aus den RFC-Veröffentlichungen, genauer aus der 1996 erschienen Veröffentlichung des
HTTP-Protokolls 1.0 :
RFC 1945-Hypertext Transfer Protocol--HTTP/1.0
| Accept (request) |
|
The Accept request-header field can be used to indicate a list of
media ranges which are acceptable as a response to the request. The
asterisk "*" character is used to group media types into ranges, with
"*/*" indicating all media types and "type/*" indicating all subtypes
of that type. The set of ranges given by the client should represent
what types are acceptable given the context of the request.
Example: Accept: text/xml,application/xml,text/html,text/plain,video/x-mng,image/png,image/jpeg,image/gif,text/css,*/* |
| Accept-Charset (request) |
|
The Accept-Charset request-header field can be used to indicate a
list of preferred character sets other than the default US-ASCII and
ISO-8859-1. This field allows clients capable of understanding more
comprehensive or special-purpose character sets to signal that
capability to a server which is capable of representing documents in
those character sets.
Example: Accept-Charset: ISO-8859-1, utf-8, * |
| Accept-Encoding (request) |
|
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-coding values which are acceptable in the
response.
Example Accept-Encoding: gzip, deflate |
| Accept-Language (request) |
|
The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request.
Example Accept-Language: en-us, en, de |
| Allow (request/response) |
|
The Allow entity-header field lists the set of methods supported by
the resource identified by the Request-URI. The purpose of this field
is strictly to inform the recipient of valid methods associated with
the resource. The Allow header field is not permitted in a request
using the POST method, and thus should be ignored if it is received
as part of a POST entity.
Example: Allow: GET, HEAD |
| Authorization (request) |
|
A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after receiving a 401 response--may do
so by including an Authorization request-header field with the
request. The Authorization field value consists of credentials
containing the authentication information of the user agent for the
realm of the resource being requested.
Example: Authorization: Basic aGVyYmVydCBtYXggc3RyYXViOm1heA== |
| Content-Encoding (request/response) |
|
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
coding has been applied to the resource, and thus what decoding
mechanism must be applied in order to obtain the media-type
referenced by the Content-Type header field. The Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.
Example: Content-Encoding: x-gzip |
| Content-Language (request/response) |
|
The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity. Note
that this may not be equivalent to all the languages used within the
entity.
Example: Content-Language: de |
| Content-Length (request/response) |
|
Indicates the size of the body, the requests data portion.
A valid Content-Length field value is required on all HTTP/1.0 request messages
containing a body. Any Content-Length greater than or equal to zero is a valid value.
Example: Content-Length: 1234 |
| Content-Type (request/response) |
|
The Content-Type entity-header field indicates the media type of the
Entity-Body sent to the recipient or, in the case of the HEAD method,
the media type that would have been sent had the request been a GET.
Example: Content-Type: text/plain, text/html |
| Date (request/response) |
|
The Date general-header field represents the date and time at which
the message was originated, having the same semantics as orig-date in
RFC 822. The field value is an HTTP-date, as described in Section
3.3.
Example: Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Expires (request/response) |
|
The Expires entity-header field gives the date/time after which the
entity should be considered stale. This allows information providers
to suggest the volatility of the resource, or a date after which the
information may no longer be valid. Applications must not cache this
entity beyond the date given. The presence of an Expires field does
not imply that the original resource will change or cease to exist
at, before, or after that time. However, information providers that
know or even suspect that a resource will change by a certain date
should include an Expires header with that date. The format is an
absolute date and time as defined by HTTP-date in Section 3.3.
Example: Expires: Thu, 01 Dec 1994 16:00:00 GMT |
| From (request) |
|
The From request-header field, if given, should contain an Internet
e-mail address for the human user who controls the requesting user
agent. The address should be machine-usable, as defined by mailbox in
RFC 822 [7] (as updated by RFC 1123 [6]):
Example: From: webmaster@w3.org |
| If-Modified-Since (request) |
|
The If-Modified-Since request-header field is used with the GET
method to make it conditional: if the requested resource has not been
modified since the time specified in this field, a copy of the
resource will not be returned from the server; instead, a 304 (not
modified) response will be returned without any Entity-Body.
Example: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| Last-Modified (request/response) |
|
The Last-Modified entity-header field indicates the date and time at
which the sender believes the resource was last modified. The exact
semantics of this field are defined in terms of how the recipient
should interpret it: if the recipient has a copy of this resource
which is older than the date given by the Last-Modified field, that
copy should be considered stale.
Example: Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| Location (response) |
|
The Location response-header field defines the exact location of the
resource that was identified by the Request-URI. For 3xx responses,
the location must indicate the server's preferred URL for automatic
redirection to the resource. Only one absolute URL is allowed.
Example: Location: http://www.w3.org/hypertext/WWW/NewLocation.html |
| Referer (request) |
|
The Referer request-header field allows the client to specify, for
the server's benefit, the address (URI) of the resource from which
the Request-URI was obtained. This allows a server to generate lists
of back-links to resources for interest, logging, optimized caching,
etc. It also allows obsolete or mistyped links to be traced for
maintenance. The Referer field must not be sent if the Request-URI
was obtained from a source that does not have its own URI, such as
input from the user keyboard.
Example: Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
| Retry-After (response) |
|
The Retry-After response-header field can be used with a 503 (service
unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. The value of this field can
be either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response.
Example: Retry-After: 600 |
| Server (response) |
|
The Server response-header field contains information about the
software used by the origin server to handle the request. The field
can contain multiple product tokens (Section 3.7) and comments
identifying the server and any significant subproducts. By
convention, the product tokens are listed in order of their
significance for identifying the application.
Example: Apache/2.0.45 (Win32) mod_jk2/2.0.2 |
| User-Agent (request) |
|
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. Although it is not required, user agents should
include this field with requests. The field can contain multiple
product tokens (Section 3.7) and comments identifying the agent and
any subproducts which form a significant part of the user agent. By
convention, the product tokens are listed in order of their
significance for identifying the application.
Example: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 |
| WWW-Authenticate (response) |
|
The WWW-Authenticate response-header field must be included in 401
(unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI.
Example: WWW-Authenticate: BASIC realm="geschützter Bereich" |
|
|
|