Difference between revisions of "HTTP headers"

From Seobility Wiki
Jump to: navigation, search
(→‎Similar articles)
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
<seo title="HTTP headers" metadescription="In this article, you'll learn what an HTTP header is and see some examples of possible header fields." />
+
<seo title="What are HTTP Headers? Definition + Examples" metadescription="The HTTP header is part of the Hypertext Transfer Protocol (HTTP) and transmits additional information during HTTP requests or responses. Learn more ..." />
 +
== Definition ==
 +
[[File:HTTP-Header.png|thumb|450px|right|alt=HTTP Header|'''Figure:''' HTTP Header - Author: Seobility - License: [[Creative Commons License BY-SA 4.0|CC BY-SA 4.0]]|link=https://www.seobility.net/en/wiki/images/d/d2/HTTP-Header.png]]
  
−
__NOTOC__
+
The HTTP header is part of the Hypertext Transfer Protocol (HTTP) and transmits additional information during HTTP requests or responses. In addition to the data that is delivered to a browser by the web server of the called website, server and browser exchange meta information about the document via the HTTP header.
  
−
== Definition ==
+
An HTTP request contains a header area with information such as the date of the request, the referrer, or the preferred language. The HTTP response also contains a header field in which the server sends its information to the user's browser. This information exchange is usually invisible to the end user.
  
−
HTTP headers are part of data transfer on the internet. HTTP is the abbreviation for Hypertext Transfer Protocol. Before data of a requested website is delivered from a web server to a browser, the server and browser exchange so-called meta information about the document or website via the HTTP header.
+
HTTP headers include fields which themselves consist of one line. Each line contains a name/value pair - called key-value pair -  separated by a colon and is terminated by a line break.
  
−
With the HTTP request, browsers transmit information about the date of the request, preferred language, or referrer to a server. This information is answered by the server with an HTTP response header in the response message.
+
Values that can be used for the HTTP header are defined in the RFC ("Requests for Comments"). In addition to the specified fields, there are also non-standard headers that can be used to add user-defined information. These headers usually start with an <code>x-</code>.
  
−
[[File:http-request-and-response.png|link=|700px]]
+
== Examples of Request Header Fields ==
  
−
Figure: HTTP request and response, Author: Seobility
+
Below, you can see some examples of possible request header fields. For a comprehensive overview of all request and response header fields, see https://en.wikipedia.org/wiki/List_of_HTTP_header_fields.
  
−
The HTTP request or response header contains so-called fields, which consist of one line each. Each line contains a name/value pair separated by a colon and is terminated by a CRLF character string (CR = carriage return and LF = line feed).
+
=== Accept Fields ===
  
−
Values that can be used for an HTTP request or response header are defined in RFC ("Requests for Comments"). These are formal documents of the Internet Engineering Task Force (IETF), which include standards used on the internet.
+
The following fields are used to specify what kind of response is accepted by the server.
  
−
== Examples of Request Header Fields ==
+
'''Accept'''
−
 
 
−
Below, you can see some examples of possible request header fields. For a comprehensive overview of all request and response header fields, see https://en.wikipedia.org/wiki/List_of_HTTP_header_fields.
 
  
−
=== Accept ===
+
This field informs the server what kind of data can be returned.
  
−
The Accept field in an HTTP request can be used to specify certain media types that are accepted by the client. The general syntax is as follows:
+
The Accept field in the HTTP request can be used to specify certain MIME types that are accepted by the client. The general syntax is as follows:
  
−
<pre>Accept: type/subtype [q=qvalue]</pre>
+
<pre>Accept: <MIME_type>/<MIME_subtype> ;q=value</pre>
  
 
Multiple media types can be separated by commas. The optional value q represents the quality level on a scale from 0 to 1. Example:
 
Multiple media types can be separated by commas. The optional value q represents the quality level on a scale from 0 to 1. Example:
Line 31: Line 31:
 
<pre>Accept: text/plain; q = 0,5, text/html, text/x-dvi; q = 0.8, Text/x-c</pre>
 
<pre>Accept: text/plain; q = 0,5, text/html, text/x-dvi; q = 0.8, Text/x-c</pre>
  
−
=== Accept-Charset ===
+
'''The available directives are:'''
 +
 
 +
* The client supports exactly one MIME type such as text/html:
 +
 
 +
<pre><MIME_type>/<MIME_subtype></pre>
 +
 
 +
* A MIME type without a specified subtype. image/* matches image/png, image/svg, image/gif and all other image types:
 +
 
 +
<pre><MIME_type>/*</pre>
 +
 
 +
* Any MIME type:
 +
 
 +
<pre>*/*</pre>
 +
 
 +
Each value used is put into a preference order that is expressed using the relative quality value called weight:
 +
 
 +
<pre>;q= (q-factor weighting)</pre>
 +
 
 +
'''Accept-Charset'''
  
 
The Accept-Charset field is used in HTTP headers to specify which [[Character Encoding|character sets]] the client accepts for the response.
 
The Accept-Charset field is used in HTTP headers to specify which [[Character Encoding|character sets]] the client accepts for the response.
Line 41: Line 59:
 
<pre>Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8</pre>
 
<pre>Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8</pre>
  
−
=== Accept-Encoding ===
+
'''Accept-Encoding'''
  
−
The Accept-Encoding header field limits the encodings that are acceptable in the response. Syntax:
+
The Accept-Encoding header field limits the encoding algorithms that are acceptable in the response. Syntax:
  
 
<pre>Accept-Encoding: encodings</pre>
 
<pre>Accept-Encoding: encodings</pre>
Line 53: Line 71:
 
<pre>Accept-Encoding: *</pre>
 
<pre>Accept-Encoding: *</pre>
  
−
<pre>Accept-Encoding: gzip; q = 0.7</pre>
+
<pre>Accept-Encoding: gzip;q=0.7</pre>
  
−
=== Accept-Language ===
+
'''Accept-Language'''
  
−
The Accept-Language header field limits the set of natural languages that are preferred in response to the request. The syntax is:
+
The Accept-Language header field tells the server what human-readable language the server is expected to return. This is an indication and is not necessarily completely controlled by the user. The server should always avoid overriding an explicit user selection. The syntax is:
  
−
<pre>Accept-Language: language; q=qvalue</pre>
+
<pre>Accept-Language: <language>; q=qvalue</pre>
  
 
Multiple languages can be separated by commas. For example:
 
Multiple languages can be separated by commas. For example:
  
−
<pre>Accept-Language: en-US; q = 0.9</pre>
+
<pre>Accept-Language: en-US; q=0.9</pre>
  
 
Allowed values can be looked up in RFC 1766.
 
Allowed values can be looked up in RFC 1766.
Line 69: Line 87:
 
=== Authorization ===
 
=== Authorization ===
  
−
The Authorization field is used in HTTP headers to send login information to a server. The syntax is as follows:
+
The Authorization field is used in HTTP headers to authenticate a user-agent with the server. The syntax is as follows:
  
−
<pre>Authorization: login information</pre>
+
<pre>Authorization:<type> <credentials></pre>
  
 
=== Cookie ===
 
=== Cookie ===
  
−
The cookie header field contains a name/value pair with information stored for the requested URL. Multiple cookie information can be specified here:
+
The [[Cookie]] HTTP Request header contains stored HTTP cookies in name/value pairs previously sent by the server using the Set-Cookie header. This behavior can be blocked by browsers so that no cookies are transmitted to the server.
  
 
<pre>Cookie: name1=value1; name2=value2; name3=value3</pre>
 
<pre>Cookie: name1=value1; name2=value2; name3=value3</pre>
Line 93: Line 111:
 
<pre>From: [email protected]</pre>
 
<pre>From: [email protected]</pre>
  
−
The From field can be used in HTTP headers for logging purposes and for identification.
+
The From field can be used in HTTP headers for logging purposes.
  
 
=== Host ===
 
=== Host ===
Line 103: Line 121:
 
If the port number is missing, this implies the default port 80.
 
If the port number is missing, this implies the default port 80.
  
−
=== If-Match ===
+
=== If Fields ===
 +
 
 +
The following fields are used to specify certain conditions under which the requested files should be returned.
  
−
This header field prompts the server to send the requested file only if it matches the specified entity tags. The syntax is:
+
'''If-Match'''
 +
 
 +
This header field prompts the server to send the requested file only if it matches the specified [[Entity|entity]] tags. The syntax is:
  
 
<pre>If-Match: entity-tag</pre>
 
<pre>If-Match: entity-tag</pre>
Line 115: Line 137:
 
An asterisk (*) indicates that any file can be sent.
 
An asterisk (*) indicates that any file can be sent.
  
−
=== If-Modified-Since ===
+
'''If-Modified-Since'''
  
 
If If-Modified-Since is specified in HTTP headers, a requested resource will only be delivered by the server if it has been changed since the specified date. Otherwise, there will be no delivery and the page will be loaded from the cache of the browser. Syntax:
 
If If-Modified-Since is specified in HTTP headers, a requested resource will only be delivered by the server if it has been changed since the specified date. Otherwise, there will be no delivery and the page will be loaded from the cache of the browser. Syntax:
Line 125: Line 147:
 
<pre>If-Modified-Since: Sat, 13 Oct 2017 15:16:27 GMT</pre>
 
<pre>If-Modified-Since: Sat, 13 Oct 2017 15:16:27 GMT</pre>
  
−
=== If-None-Match ===
+
'''If-None-Match'''
  
 
This header prompts the server to send the requested file only if it does not match any of the specified entity tags. The syntax is:
 
This header prompts the server to send the requested file only if it does not match any of the specified entity tags. The syntax is:
Line 137: Line 159:
 
<pre>If-None-Match: *</pre>
 
<pre>If-None-Match: *</pre>
  
−
=== If-Range ===
+
'''If-Range'''
  
 
The If-Range header field is used in HTTP headers to request only the part of the content that is missing if the content has not been changed, and the entire content if a change has been made to it. The syntax is as follows:
 
The If-Range header field is used in HTTP headers to request only the part of the content that is missing if the content has not been changed, and the entire content if a change has been made to it. The syntax is as follows:
Line 149: Line 171:
 
If the content has not been changed, the server returns the byte range specified by the range header. Otherwise, the entire new document is returned.
 
If the content has not been changed, the server returns the byte range specified by the range header. Otherwise, the entire new document is returned.
  
−
=== If-Unmodified-Since ===
+
'''If-Unmodified-Since'''
  
 
The general syntax is:
 
The general syntax is:
Line 156: Line 178:
  
 
This field is used in the same way as the If-Modified-Since field.
 
This field is used in the same way as the If-Modified-Since field.
−
 
−
=== Max-Forwards ===
 
−
 
−
Max-Forwards tells proxy servers the maximum number of times a message can be forwarded. The syntax is as follows:
 
−
 
−
<pre>Max-Forwards: n</pre>
 
−
 
−
The Max-Forwards value "n" is a decimal number. Max-Forwards is useful for debugging with the TRACE method, avoiding endless loops. The Max-Forwards header field can be ignored for all other methods defined in the HTTP specification.
 
  
 
=== Proxy-Authorization ===
 
=== Proxy-Authorization ===
Line 169: Line 183:
 
The Proxy-Authorization header field allows the client to identify itself or the user to a proxy. Syntax:
 
The Proxy-Authorization header field allows the client to identify itself or the user to a proxy. Syntax:
  
−
<pre>Proxy-Authorization: login information</pre>
+
<pre>Proxy-Authorization: <type> <credentials></pre>
  
 
=== Range ===
 
=== Range ===
  
−
The range request-header field specifies the subranges of content that are requested. The syntax is:
+
The Range header field specifies the subranges of content that are requested. The syntax is:
  
 
<pre>Range: bytes-unit=first-byte-pos "-" [last-byte-pos]</pre>
 
<pre>Range: bytes-unit=first-byte-pos "-" [last-byte-pos]</pre>
Line 188: Line 202:
  
 
<pre>Referer: http://www.example.com</pre>
 
<pre>Referer: http://www.example.com</pre>
−
 
−
=== TE ===
 
−
 
−
The TE header field specifies which extension transfer encoding is accepted in the response. The syntax is:
 
−
 
−
<pre>TE: transfer encodings</pre>
 
  
 
=== User-Agent ===
 
=== User-Agent ===
Line 199: Line 207:
 
This header field sends information about the client to a server. For example, the syntax can be as follows:
 
This header field sends information about the client to a server. For example, the syntax can be as follows:
  
−
<pre>User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36</pre>
+
<pre>User-Agent: <product>/<product version> <comment></pre>
  
 
== Similar articles ==
 
== Similar articles ==
Line 206: Line 214:
  
 
[[Category:Web Development]]
 
[[Category:Web Development]]
 +
 +
<html><script type="application/ld+json">
 +
    {
 +
      "@context": "https://schema.org/",
 +
      "@type": "ImageObject",
 +
      "contentUrl": "https://www.seobility.net/en/wiki/images/d/d2/HTTP-Header.png",
 +
      "license": "https://creativecommons.org/licenses/by-sa/4.0/",
 +
      "acquireLicensePage": "https://www.seobility.net/en/wiki/Creative_Commons_License_BY-SA_4.0"
 +
    }
 +
    </script></html>
 +
 +
{| class="wikitable" style="text-align:left"
 +
|-
 +
|'''About the author'''
 +
|-
 +
| [[File:Seobility S.jpg|link=|100px|left|alt=Seobility S]] The Seobility Wiki team consists of seasoned SEOs, digital marketing professionals, and business experts with combined hands-on experience in SEO, online marketing and web development. All our articles went through a multi-level editorial process to provide you with the best possible quality and truly helpful information. Learn more about <html><a href="https://www.seobility.net/en/wiki/Seobility_Wiki_Team" target="_blank">the people behind the Seobility Wiki</a></html>.
 +
|}
 +
 +
<html><script type="application/ld+json">
 +
{
 +
  "@context": "https://schema.org",
 +
  "@type": "Article",
 +
  "author": {
 +
    "@type": "Organization",
 +
    "name": "Seobility",
 +
    "url": "https://www.seobility.net/"
 +
  }
 +
}
 +
</script></html>

Latest revision as of 16:10, 6 December 2023

Definition

HTTP Header
Figure: HTTP Header - Author: Seobility - License: CC BY-SA 4.0

The HTTP header is part of the Hypertext Transfer Protocol (HTTP) and transmits additional information during HTTP requests or responses. In addition to the data that is delivered to a browser by the web server of the called website, server and browser exchange meta information about the document via the HTTP header.

An HTTP request contains a header area with information such as the date of the request, the referrer, or the preferred language. The HTTP response also contains a header field in which the server sends its information to the user's browser. This information exchange is usually invisible to the end user.

HTTP headers include fields which themselves consist of one line. Each line contains a name/value pair - called key-value pair - separated by a colon and is terminated by a line break.

Values that can be used for the HTTP header are defined in the RFC ("Requests for Comments"). In addition to the specified fields, there are also non-standard headers that can be used to add user-defined information. These headers usually start with an x-.

Examples of Request Header Fields

Below, you can see some examples of possible request header fields. For a comprehensive overview of all request and response header fields, see https://en.wikipedia.org/wiki/List_of_HTTP_header_fields.

Accept Fields

The following fields are used to specify what kind of response is accepted by the server.

Accept

This field informs the server what kind of data can be returned.

The Accept field in the HTTP request can be used to specify certain MIME types that are accepted by the client. The general syntax is as follows: 

Accept: <MIME_type>/<MIME_subtype> ;q=value

Multiple media types can be separated by commas. The optional value q represents the quality level on a scale from 0 to 1. Example: 

Accept: text/plain; q = 0,5, text/html, text/x-dvi; q = 0.8, Text/x-c

The available directives are:

  • The client supports exactly one MIME type such as text/html:
<MIME_type>/<MIME_subtype>
  • A MIME type without a specified subtype. image/* matches image/png, image/svg, image/gif and all other image types:
<MIME_type>/*
  • Any MIME type:
*/*

Each value used is put into a preference order that is expressed using the relative quality value called weight: 

;q= (q-factor weighting)

Accept-Charset

The Accept-Charset field is used in HTTP headers to specify which character sets the client accepts for the response. 

Accept-Charset: character-set

If several character sets are specified, enter them separated by commas. For example: 

Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8

Accept-Encoding

The Accept-Encoding header field limits the encoding algorithms that are acceptable in the response. Syntax: 

Accept-Encoding: encodings

Examples are: 

Accept-Encoding: gzip
Accept-Encoding: *
Accept-Encoding: gzip;q=0.7

Accept-Language

The Accept-Language header field tells the server what human-readable language the server is expected to return. This is an indication and is not necessarily completely controlled by the user. The server should always avoid overriding an explicit user selection. The syntax is: 

Accept-Language: <language>; q=qvalue

Multiple languages can be separated by commas. For example: 

Accept-Language: en-US; q=0.9

Allowed values can be looked up in RFC 1766.

Authorization

The Authorization field is used in HTTP headers to authenticate a user-agent with the server. The syntax is as follows: 

Authorization:<type> <credentials>

Cookie

The Cookie HTTP Request header contains stored HTTP cookies in name/value pairs previously sent by the server using the Set-Cookie header. This behavior can be blocked by browsers so that no cookies are transmitted to the server. 

Cookie: name1=value1; name2=value2; name3=value3

Expect

The HTTP request header field Expect specifies the client's expectations that must be met by a server for the request to be processed properly.

The general syntax is as follows: 

Expect : 100-continue

From

The From field of HTTP headers contains an email address of the user who controls the requesting client. Example: 

From: [email protected]

The From field can be used in HTTP headers for logging purposes.

Host

The Host field is used in HTTP headers to specify the internet host and port number for the requested resource. The syntax is: 

Host: host:port

If the port number is missing, this implies the default port 80.

If Fields

The following fields are used to specify certain conditions under which the requested files should be returned.

If-Match

This header field prompts the server to send the requested file only if it matches the specified entity tags. The syntax is: 

If-Match: entity-tag

For example: 

If-Match: "*"

An asterisk (*) indicates that any file can be sent.

If-Modified-Since

If If-Modified-Since is specified in HTTP headers, a requested resource will only be delivered by the server if it has been changed since the specified date. Otherwise, there will be no delivery and the page will be loaded from the cache of the browser. Syntax: 

If-Modified-Since: HTTP date

An example is: 

If-Modified-Since: Sat, 13 Oct 2017 15:16:27 GMT

If-None-Match

This header prompts the server to send the requested file only if it does not match any of the specified entity tags. The syntax is: 

If-None-Match: entity-tag

Examples are: 

If-None-Match: "xyzzy"
If-None-Match: *

If-Range

The If-Range header field is used in HTTP headers to request only the part of the content that is missing if the content has not been changed, and the entire content if a change has been made to it. The syntax is as follows: 

If-Range: entity-tag/HTTP date

Either an entity tag or a date can be used: 

If-Range: Sat, 13 Oct 2017 15:16:27 GMT

If the content has not been changed, the server returns the byte range specified by the range header. Otherwise, the entire new document is returned.

If-Unmodified-Since

The general syntax is: 

If-Unmodified-Since: HTTP date

This field is used in the same way as the If-Modified-Since field.

Proxy-Authorization

The Proxy-Authorization header field allows the client to identify itself or the user to a proxy. Syntax: 

Proxy-Authorization: <type> <credentials>

Range

The Range header field specifies the subranges of content that are requested. The syntax is: 

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

The values "first-byte-pos" and "last-byte-pos" specify the first and last bytes of the included content, but do not have to be both specified. Multiple content areas can be separated by commas.

Referrer

The Referrer header field allows the client to specify the address (URL) of the resource from which the URL was requested. The general syntax is as follows: 

Referer: URL

For example: 

Referer: http://www.example.com

User-Agent

This header field sends information about the client to a server. For example, the syntax can be as follows: 

User-Agent: <product>/<product version> <comment>

Similar articles

About the author
Seobility S
The Seobility Wiki team consists of seasoned SEOs, digital marketing professionals, and business experts with combined hands-on experience in SEO, online marketing and web development. All our articles went through a multi-level editorial process to provide you with the best possible quality and truly helpful information. Learn more about the people behind the Seobility Wiki.