HTTP Headers are an important part of HTTP communication. Each HTTP request and HTTP response usually contain multiple headers. Intermediaries such as proxies often interpret some of the headers and pass on or filter out others.

A Client can send an HTTP header X-Request-ID: some-value. The server should use the provided value and provide it in any requests that it makes to backend services for the purpose of serving the initial the request. When sending the response, the server will return the same header back to the client. For the purpose of tracing, the server will include the value into its logs, to enable correlating requests and responses with the corresponding logs.

Accept-Charset takes a number of character sets and includes an optional preference for which one the server should use. The charset is one from the list of available charsets at IANA "Character Sets" registry. For example UTF-8.

The charset is separated by commas with an optional quality factor (using a ;q=) that is used the clients preference for using this type. The quality factor has a value from 0 to 1 with the higher the number the more preference for that type.

If this header is not included then the client will accept any charset.

The server uses Content-Type to inform the client what character set it is using.

If the server can't find an acceptable charset to reply with then it should send a 406 (not acceptable) response or ignore this header and not doing any content negotiation.

The content types are MIME types (ie text/html) separated by comma with an optional quality factor (using a ;q=) that is used the clients preference for using this type. The quality factor has a value from 0 to 1 with the higher the number the more preference for that type.

If the server can't find an acceptable type to reply with then it should send a 406 (not acceptable) response.

Accept-Encoding takes a number of encoding and includes an optional preference for which one the server should use. The encoding is one from the list of available encodings at IANA registry. For example gzip.

The encoding is separated by commas with an optional quality factor (using a ;q=) that is used the clients preference for using this encoding. The quality factor has a value from 0 to 1 with the higher the number the more preference for that encoding.

If this header is not included then the client does not state any preference for the encoding. It does not mean that the client supports all encodings.

A value of identity is always acceptable unless you reject it with identity;q=0.

The server uses Content-Encoding to inform the client what encoding it is using.

If the server can't find an acceptable charset to reply with then it should send a 406 (not acceptable) response or ignore this header and not doing any content negotiation.

Accept-Language takes a number of languages and includes an optional preference for which one the server should use. The language is one from the list of available at IANA Language Subtag Registry page. For example en is English, and en-US is USA English.

The language is separated by commas with an optional quality factor (using a ;q=) that is used the clients preference for using this language. The quality factor has a value from 0 to 1 with the higher the number the more preference for that language.

If this header is not included then the client will accept any language.

The server uses Content-Language to inform the client what langauge it is using.

Accept-Ranges is part of the ranges system. The ranges system lets the client request only part of a file instead of having to download the whole file.

For example if a client only needs the last 100 bytes of a 10M file it can request the server only send data from offset 10485660 to 10485760.

Accept-Ranges is sent from the server to tell the client if it supports ranges. This only applies to this particular resource (file), other files may accept different range types.

Only two values are currently defined, bytes and none. The values bytes means that you can request byte ranges (offset and end will be in bytes). A value of 'none' means the server does not support ranges.

Clients are free to request byte range requests without checking if the server supports ranges.

The client uses Range to request a range from the server and the server replies with a status of 206 (Partial Content) if it is sending the range of bytes or 200 (ok) if it is going to send the whole file.