HTTP Request Headers

This page provides information about HTTP request headers. It provides a list of request methods and HTTP request header fields. The information on this page includes partial quotes from RFC 2616 that are somewhat re-organized.

A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.

Request = Request-Line 	;  
	*(( general-header 	;
	| request-header 	;
	| entity-header ) CRLF) ;
	[ message-body ] 	;

The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive" Methods are:

  • OPTIONS - Represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
  • GET - Retrieve whatever information (in the form of an entity) is identified by the Request-URI.
  • HEAD - Identical to GET except that the server MUST NOT return a message-body in the response.
  • POST - Used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
    • Annotation of existing resources
    • Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
    • Providing a block of data, such as the result of submitting a form, to a data-handling process
    • Extending a database through an append operation.
  • PUT - Requests that the enclosed entity be stored under the supplied Request-URI.
  • DELETE - Requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully.
  • TRACE - Used to invoke a remote, application-layer loop- back of the request message.
  • CONNECT - Reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.

Request-URI = "*" | absoluteURI | abs_path | authority

The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be


The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:


Request header fields:

  • ACCEPT - Can be used to specify certain media types, in MIME format, which are acceptable for the response from the web server Contains a list of media types, in MIME format, that the Web browser can accept from the Web server.
  • Accept-Charset - Can be used to indicate what character sets are acceptable for the response. 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.
  • ACCEPT-ENCODING - Tells the web server what document encoding methods the Web browser supports. Examples of its use are:
    Accept-Encoding: compress, gzip 
    Accept-Encoding: * 
    Accept-Encoding: compress;q=0.5, gzip;q=1.0 
    Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
  • ACCEPT-LANGUAGE - Tells the web server the web browser's preferred natural language.
  • AUTHORIZATION - The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
  • Expect - Used to indicate that particular server behaviors are required by the client.
  • FROM - An Internet e-mail address for the human user who controls the requesting user agent. The user's e-mail address who sent the HTTP request. This is not supported by most browsers.
  • Host - Specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource.
  • If-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field.
  • IF-MODIFIED-SINCE - This is a HTTP data value that tells the server to only return the requested file if it was modified after the date. Form:

    If-Modified-Since = "If-Modified-Since" ":" HTTP-date


    If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

  • If-None-Match - Used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist.
  • If-Range - If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body. The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
  • If-Unmodified-Since - Used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server SHOULD perform the requested operation as if the If-Unmodified-Since header were not present.
  • Max-Forwards - Provides a mechanism with the TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.
  • Proxy-Authorization - Allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
  • Range - Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte- range operations.)
  • REFERER - The Referer[sic] 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 is the URI of the document that the user clicked on to get the current document.
  • TE - Indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters .
  • USER-AGENT - 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. User agents SHOULD include this field with requests. This is information about the client web browser such as Mozilla/4.01 [en] (Win95; I).