Advanced   Java   Services HTTP 1.0 Headernames Back Next Up Home

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:

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:

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:

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"

Valid XHTML 1.0 Strict top Back Next Up Home