HTTP Header Detailed

There are four types of HTTP header fields:
General header
Request header
Response header
Entity header. Entity header
*******************************************************************************
General Header Fields
=============================
General header is available for request and response, but not for entity
－－ Cache-Control
－－ Connection
D
－－ Pragma
－－ Trailer
－－ Transfer-Encoding
－－ Upgrade
- V
－－ Warning
*******************************************************************************
Request Header Fields
======================
Request header fields allow clients to pass additional information about request and clients to the server,
－－ Accept
－－ Accept-Charset
－－ Accept-Encoding
－－ Accept-Language
－－ Authorization
－－ Expect
- Fu M.
- host
－－ If-Match
－－ If-Modified-Since
－－ If-None-Match
－－ If-Range
－－ If-Unmodified-Since
－－ Max-Forwards
－－ Proxy-Authorization
- lucky
－－ Referer
- t
－－ User-Agent
*******************************************************************************
Response Header Fields
===============================
Response header fields allow the server to pass additional information about response that cannot be placed in status line.
These headers give information about the server.
－－ Accept-Ranges
Ah Ge
E.
－－ Location
－－ Proxy-Authenticate
－－ Retry-After
－－ Server
- Victoria
－－ WWW-Authenticate
*******************************************************************************
Entity Header Fields
========================
Entity header fields define the metadata about the entity body,
If there is no body, the resource information determined by the request is defined
Some of the metadata is optional; some is required.
- al low
－－ Content-Encoding
－－ Content-Language
－－ Content-Length
－－ Content-Location
－－ Content-MD5
－－ Content-Range
－－ Content-Type
－－ Expires
－－ Last-Modified
－－ extension-header
1、 Basic
HTTP (Hypertext Transfer Protocol) is the abbreviation of hypertext transfer protocol, which is used to transfer data in the way of www. for details of HTTP protocol, please refer to rfc2616. The HTTP protocol uses a request / response model. The client sends a request to the server. The request header contains the method, URI, protocol version, and mime like message structure containing the request modifier, customer information and content. The server responds with a status line. The corresponding content includes the version of the message protocol, the success or error code plus the server information, entity meta information and possible entity content.
Generally, HTTP messages include request messages from client to server and response messages from server to client. These two types of messages are composed of a starting line, one or more header fields, an empty line only ending the header field and an optional message body. The header field of HTTP includes four parts: General header, request header, response header and entity header. Each header domain consists of a domain name, a colon (:), and a domain value. The domain name is case independent. Any number of space characters can be added before the domain value. The header field can be extended to multiple lines. At the beginning of each line, at least one space or tab character is used.
1. Common header domain
The common header domain includes the header domains supported by both request and response messages. The common header domain includes cache control, connection, date, pragma, transfer encoding, upgrade, and via. The extension of the universal header domain requires that both sides of communication support this extension. If there is an unsupported universal header domain, it will be treated as an entity header domain. The following is a brief introduction to several common header domains used in UPnP messages.
Cache control header domain
Cache control specifies the caching mechanism that requests and responses follow. Setting cache control in a request or response message does not modify the cache processing in another message processing. The cache instructions in the request include no cache, no store, Max age, Max stale, min fresh and only if cached. The instructions in the response message include public, private, no cache, no store, no transform, most revalidate, proxy revalidate and Max age. The meaning of the instructions in each message is as follows:
Public indicates that the response can be cached by any cache.
Private indicates that the entire or partial response message to a single user cannot be processed by the shared cache. This allows the server to describe only part of a response message that is not valid for other users' requests.
No cache indicates that the request or response message cannot be cached
No store is used to prevent important information from being inadvertently released. Sending in a request message will make the request and response messages do not use caching.
Max age indicates that the client can receive a response with a lifetime of no more than a specified time in seconds.
Min-fresh indicates that the client can receive a response that takes less than the current time plus the specified time.
Max stale indicates that the client can receive response messages that exceed the timeout period. If you specify a value for the max stale message, the client can receive a response message that exceeds the value specified for the timeout period.
Date header domain
The date header field represents the time when the message was sent, and the description format of the time is defined by rfc822. For example, date: Mon, 31dec200104:25:57gmt. The time described by date represents the world standard time, which is converted to local time, and the user's time zone needs to be known.
Pragma header domain
The pragma header field is used to contain implementation specific instructions. The most commonly used one is pragma: no cache. In http / 1.1 protocol, it has the same meaning as cache control: no cache.
2. Request message
The first line of the request message is in the following format:
Method SP Request-URI SP HTTP-Version CRLF
Method indicates the method completed for request URI. This field is case sensitive, including options, get, head, post, put, delete, trace. Methods get and head should be supported by all general web servers, and the implementation of all other methods is optional. The get method retrieves the information identified by the request URI. The head method also retrieves the information identified by the request URI, except that when responding, it does not return the message body. The post method can request the server to receive the entity information contained in the request. It can be used to submit forms and send messages to newsgroups, BBS, mail groups and databases.
SP stands for space.
The request URI follows the URI format. When the field is asterisk (*), it means that the request is not used for a specific resource address, but for the server itself.
HTTP version indicates the supported HTTP version, for example, http / 1.1.
CRLF stands for line feed carriage return.
The request header domain allows the client to pass additional information about the request or about the client to the server. The request header field may include the following fields: accept, accept charset, accept encoding, accept language, authorization, from, host, if modified since, if match, if none match, if range, if range, if unmodified since, Max forwards, proxy authorization, range, referer, user agent. The extension of the request header domain requires the support of both sides of communication. If there is an unsupported request header domain, it will generally be treated as an entity header domain.
Typical request message:
GEThttp://class/download.microtool.de:80/somedata.exe
Host:download.microtool.de
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:http://class/download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
The first line of the above example indicates that the HTTP client (maybe the browser or the downloader) obtains the file under the specified URL through the get method. The brown part represents the information of the request header field, and the green part represents the general header.
Host header domain
The host header domain specifies the Intenet host and port number of the requested resource and must represent the location of the original server or gateway of the requested URL. The HTTP / 1.1 request must contain the host header domain, otherwise the system will return with the 400 status code.
Referer header
The referer header domain allows the client to specify the source resource address of the request URI, which allows the server to generate a fallback list, which can be used for login, cache optimization, etc. It also allows broken or faulty connections to be tracked for maintenance purposes. If the requested URI does not have its own URI address, the referer cannot be sent. If a partial URI address is specified, it should be a relative address.
Range header domain
The range header field can request one or more child ranges of an entity. For example,
Indicates the first 500 bytes: bytes = 0-499
Indicates the second 500 bytes: bytes = 500-999
Indicates the last 500 bytes: bytes = - 500
Indicates the range after 500 bytes: bytes = 500-
First and last bytes: bytes = 0-0, - 1
Specify several ranges at the same time: bytes = 500-600601-999
But the server can ignore the request header. If the unconditional get contains the range request header, the response will be returned with the status code 206 (partialcontent) instead of 200 (OK).
User agent header domain
The content of the user agent header field contains the requested user information.
3. Response message
The first line of the response message is in the following format:
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP version indicates the supported HTTP version, for example, http / 1.1.
Status code is a three digit result code.
Reason Phrase provides a simple text description for status code. Status code is mainly used for automatic machine identification, and reason phrase is mainly used to help users understand. The first number of status code defines the category of the response, and the last two numbers have no role in classification. The first number may take five different values:
1XX: information response class, indicating that the request is received and processing continues
2XX: process the successful response class, indicating that the action is successfully received, understood and accepted
3xx: the redirection response class must accept further processing in order to complete the specified action
4xx: client error, client request contains syntax error or cannot be executed correctly
5xx: server error, the server cannot execute a correct request correctly
The response header fields allow the server to pass additional information that cannot be placed on the status line. These fields mainly describe the information of the server and the further information of the request URI. Response header fields include age, location, proxy authentication, public, retry after, server, vary, Warning、WWW- Authenticate。 The extension of the response header domain requires the support of both sides of communication. If there is an unsupported response header domain, it will generally be treated as an entity header domain.
Typical response message:
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes554554-40279979/40279980
The first line of the above example indicates that the HTTP server responds to a get method. The brown part represents the information of the response header field, the green part represents the general header, and the red part represents the information of the entity header field.
Location response header
The location response header is used to redirect the receiver to a new URI address.
Server response header
The server response header contains the software information of the original server that processed the request. This field can contain multiple product identifications and comments. Product identifications are generally sorted by importance.
4. Entity information
Both request message and response message can contain entity information, which is generally composed of entity header domain and entity. The entity header field contains the original information about the entity, including allow, content base, content encoding, content language, content length, content location, content MD5, content range, content type, Etag, expires, last modified, extension header. Extension header allows clients to define new entity headers, but these domains may not be recognized by the recipient. An entity can be an encoded byte stream. Its encoding method is defined by content encoding or content type, and its length is defined by content length or content range.
Content type entity header
The content type entity header is used to indicate the entity's media type to the receiver, specify the entity's media type sent by the head method to the receiver, or the request media type sent by the get method content range entity header
Content range entity header
It is used to specify the insertion position of a part of the whole entity, and it also indicates the length of the whole entity. After the server returns a partial response to the client, it must describe the scope of the response and the overall entity length. General format:
Content-Range:bytes-unit SP first-byte-pos - last-byte-pos/entity-legth
For example, the form of 500 byte fields in the delivery header: content range: bytes0-499 / 1234 if an HTTP message contains this section (for example, response to range request or overlapping request to a series of ranges), content range represents the delivery range, and content length represents the actual number of bytes delivered.
Last modified entity header
The last modified entity header specifies the last revision time of the saved content on the server.
5. HTTP header reference (Microsoft)
Both HTTP requests and HTTP responses use hair to send information about HTTP messages. The header consists of a series of lines, each containing a name followed by a colon, a space, and a value. Fields can be arranged in any order. Some header fields can be used for both request headers and response headers, while others can only be used for one of them.
Many request header fields allow clients to specify multiple acceptable options in the value section, and sometimes even rank preferences for these options. Multiple items are separated by commas. For example, the client can send a request header containing "content encoding: gzip, compress," indicating that various compression types can be accepted. If the response body of the server is gzip encoded, its response header will contain "content encoding: gzip".
Some fields can appear multiple times in a single header. For example, a header can have multiple "warning" fields.
The following table lists the HTTP 1.1 header fields. Note: some header fields are mime fields. Mime fields are defined in the Internet Engineering Task Force (IETF) document RFC 2045, but can also be used for the HTTP 1.1 protocol. For more information about mime and HTTP 1.1 specifications, see the ieif page.
General header field
General header fields can be used for request and response messages.
Name sample value
Cache-Control  "max-age=10"
Connection    "close"
Date          "Tue, 11 Jul 2000 18:23:51 GMT"
Pragma        "no-cache"
Trailer         "Date"
Transfer-Encoding "chunked"
Upgrade       "SHTTP/1.3"
Via            "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning       "112 Disconnected Operation"
Request header field
The request header field is for request messages only.
Name sample value
Accept           "text/html, image/*"
Accept-Charset   "iso8859-5"
Accept-Encoding  "gzip, compress"
Accept-Language "en, fr"
Authorization     [credentials]
Content-Encoding "gzip"
Expect           "100-continue"
From            "user@microsoft.com"
Host            "www.microsoft.com"
If-Match         "entity_tag001"
If-Modified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
If-None-Match    "entity_tag001"
If-Range         "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
Max-Forwards    "3"
Proxy-Authorization [credentials]
Range       "bytes=100-599"
Referer      "http://www.microsoft.com/resources.asp"
TE          "trailers"
User-Agent   "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
>>Specific meaning of request header field
Accept: the MIME type acceptable to the browser.
Accept charset: a character set acceptable to the browser.
Accept encoding: a data encoding method that the browser can decode, such as gzip.
Accept language: the kind of language the browser wants to use when the server can provide more than one language version.
Authorization: authorization information, which usually appears in the response to the WWW authenticate header sent by the server.
Connection: indicates whether a persistent connection is required. If the servlet sees that the value here is "keep alive", or that the request uses HTTP 1.1 (HTTP 1.1 makes persistent connection by default), it can take advantage of the advantages of persistent connection. When the page contains multiple elements (such as applet, picture), it can significantly reduce the time required for downloading. To achieve this, the servlet needs to send a content length header in the response. The simplest way is to write the content to the bytearrayoutputstream, and then calculate its size before formally writing out the content.
Content length: indicates the length of the body of the request message.
Cookie: set a cookie, which is one of the most important request headers
From: the email address of the sender of the request, which is used by some special web clients and will not be used by the browser.
Host: host and port in the initial URL.
If modified since: only when the requested content is modified after the specified date can it be returned. Otherwise, 304 "not modified" response will be returned.
Pragma: specifying the "no cache" value means that the server must return a refreshed document, even if it is a proxy server and has a local copy of the page.
Referer: contains a URL from which users can access the currently requested page.
User agent: browser type, which is useful if the content returned by the servlet is related to the browser type.
UA pixels, UA color, UA OS, UA CPU: a non-standard request header sent by some versions of IE browser, indicating screen size, color depth, operating system and CPU type.
Response header field
The response header field is for response messages only.
Name sample value
Accept-Ranges  "none"
Age            "2147483648(2^31)"
ETag           "b38b9-17dd-367c5dcd"
Last-Modified    "Tue, 11 Jul 2000 18:23:51 GMT"
Location        "http://localhost/redirecttarget.asp"
Proxy-Authenticate [challenge]
Retry-After      "Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server         "Microsoft-IIS/5.0"
Vary            "Date"
WWW-Authenticate [challenge]
Entity header field
The entity header field can be used for request or response messages. The entity header field contains information about the body of the message entity, such as the encoding format used.
Name sample value
Allow              "GET, HEAD"
Content-Encoding   "gzip"
Content-Language  "en"
Content-Length     "8445"
Content-Location   "http://localhost/page.asp"
Content-MD5       [md5-digest]
Content-Range     "bytes 2543-4532/7898"
Content-Type      "text/html"
Expires           "Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified      "Tue, 11 Jul 2000 18:23:51 GMT"
>>Specific meaning of entity header field
Which request methods (such as get, post, etc.) are supported by the allow server.
The encoding method of the content encoding document. The content type specified by the content type header can only be obtained after decoding. Using gzip to compress documents can significantly reduce the download time of HTML documents. Gzipoutputstream of Java can be easily compressed by gzip, but it is only supported by Netscape on UNIX and IE 4 and IE 5 on windows.
Content length indicates the content length. This data is only needed if the browser uses a persistent HTTP connection.
Content type indicates what MIME type the following document belongs to. The servlet defaults to text / plain, but it usually needs to be explicitly specified as text / HTML.
Date the current GMT time. You can use setdateheader to set this header to avoid the trouble of converting the time format.
When should expires think the document is out of date so that it is no longer cached?
Last modified when the document was last modified. The customer can provide a date through the if modified since request header. The request will be treated as a conditional get. Only documents with the change time later than the specified time will be returned. Otherwise, a 304 (not modified) status will be returned.
Location indicates where the customer should go to extract the document. Location is usually not set directly, but through the sendredirect method of httpservletresponse, which also sets the status code to 302.
Refresh indicates how long the browser should refresh the document in seconds. In addition to refreshing the current document, you can also let the browser read the specified page through setheader ("Refresh", "5; url = http: / / host / path").
Note that this function is usually implemented by setting < meta http-equiv = "Refresh" C > in the head area of HTML page, because automatic refresh or redirection is very important for HTML writers who cannot use CGI or servlet. However, for servlets, it is more convenient to set the refresh header directly.
Note that refresh means "refresh this page or visit the specified page after N seconds", not "refresh this page or visit the specified page every N seconds". Therefore, continuous refresh requires sending a refresh header every time, and sending 204 status code can prevent the browser from continuing to refresh, whether using the refresh header or ＜ meta http-equiv = "Refresh"... >.
Note that the refresh header is not part of the formal HTTP 1.1 specification, but is an extension, but is supported by both Netscape and ie.
Request header example
Here is a simple example of an HTTP request.
GET /articles/news/today.asp HTTP/1.1
Accept: * / *
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer: http://localhost/links.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate
The request has a request line that includes method (get), resource path (/ articles / news / today. ASP), and HTTP Version (HTTP / 1.1). Since the request has no body, the contents after all request lines are part of the header. Next to the header is a blank line, indicating that the header is over.
Response header example
The web server can respond to the previous request in many ways. Assuming the file is accessible and the user has permission to view it, the response is similar to:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 13 Jul 2000 05:46:53 GMT
Content-Length: 2291
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/
Cache-control: private
...
The first line of the response is called the status line. It contains the HTTP version, status code (200), and reason phrase used for the response. The example contains a header with five fields, followed by an empty line (carriage return and line feed), followed by the first two lines of the response body.
For a complete and detailed description of the HTTP header, see the HTTP specification at http://www.w3.org/protocols/.
Appendix: meaning of HTTP protocol status code
Status code status information meaning
100 continue the initial request has been accepted and the customer should continue to send the rest of the request. (HTTP 1.1 new)
101 switching protocols server converts the client's request to another protocol (HTTP 1.1 NEW
200 OK everything is OK. The response documents for get and post requests are followed.
201 the created server has created the document and the location header gives its URL.
202 accepted has accepted the request, but processing has not been completed.
203 the non authoritative information document has returned normally, but some reply headers may not be correct because a copy of the document is used (HTTP 1.1 new).
204 no content no new document, browser should continue to display the original document.
205 reset content has no new content, but the browser should reset what it displays. Used to force the browser to clear form input (HTTP 1.1 new).
206 the partial content client sends a get request with a range header and the server completes it (HTTP 1.1 new).
Documents requested by 300 multiple choices customers can be found in multiple locations, which are listed in the returned documents. If the server wants to give priority, it should be indicated in the location response header.
301 the documents requested by the moved permanently customer are in other places, the new URL is given in the location header, and the browser should automatically access the new URL.
302 found is similar to 301, but the new URL should be treated as a temporary alternative rather than a permanent one. Note that the corresponding status information in HTTP 1.0 is "moved temporary". When the status code appears, the browser can automatically access the new URL, so it is a very useful status code. Note that this status code can sometimes be replaced with 301. For example, if the browser incorrectly requests http: / / host / ~ user (without the following slash), some servers return 301, and some return 302. Strictly speaking, we can only assume that the browser will automatically redirect only when the original request is get. See 307.
303 see other is similar to 301 / 302, except that if the original request is post, the redirection target document specified by the location header should be extracted through get (HTTP 1.1 new).
304 not modified client has buffered documents and sends a conditional request (generally, if modified since header is provided to indicate that the client only wants to update documents later than the specified date). The server tells the client that the original buffered document can still be used.
The document requested by the 305 use proxy client should be extracted from the proxy server specified in the location header (HTTP 1.1 new).
307 temporary redirect is the same as 302 (found). Many browsers will respond to the 302 response by mistake for redirection, even if the original request is post, even if it can only be redirected when the response of the post request is 303. For this reason, 307 has been added to HTTP 1.1 to clear up and distinguish several status codes: when 303 response occurs, the browser can follow the redirected get and post requests; if 307 response occurs, the browser can only follow the redirected get requests. (HTTP 1.1 new)
Syntax error in 400 bad request request request.
401 unauthorized client attempts to access password protected pages without authorization. A WWW authenticate header will be included in the response, and the browser will display the user name / password dialog box accordingly, and then issue the request again after filling in the appropriate authorization header.
403 Forbidden resource is not available. The server understands the client's request, but refuses to process it. This is usually caused by permission settings for files or directories on the server.
404 not found cannot find the resource at the specified location. It's also a common response,
405 method not allowed request method (get, post, head, delete, put, trace, etc.) is not applicable to the specified resource. (HTTP 1.1 new)
406 not acceptable the specified resource has been found, but its MIME type is incompatible with the one specified by the customer in the accpet header (HTTP 1.1 new).
407 proxy authentication required is similar to 401, which means that the client must be authorized by the proxy server first. (HTTP 1.1 new)
408 Request Timeout the customer has not made any requests during the waiting time of the server license. The customer can repeat the same request later. (HTTP 1.1 new)
409 conflict is usually associated with a put request. The request could not succeed because it conflicts with the current state of the resource. (HTTP 1.1 new)
410 the document requested by gone is no longer available, and the server does not know which address to redirect to. It differs from 404 in that a return of 407 indicates that the document has permanently left the specified location, while 404 indicates that the document is not available for unknown reasons. (HTTP 1.1 new)
The 411 length required server cannot process requests unless the client sends a content length header. (HTTP 1.1 new)
412 some prerequisites specified in the precondition failed request header failed (HTTP 1.1 new).
413 the size of the request entity too large target document exceeds the size the server is currently willing to process. If the server thinks it can process the request later, it should provide a retry after header (HTTP 1.1 new).
414 request URI too long URI (HTTP 1.1 new).
416 requested range not satisfied the range header specified by the customer in the request. (HTTP 1.1 new)
The 500 Internal Server Error server encountered an unexpected situation and was unable to complete the customer's request.
The 501 not implemented server does not support the functionality required to implement the request. For example, the client made a put request that the server does not support.
When 502 bad gateway server acts as gateway or agent, in order to complete the request to access the next server, but the server returns an illegal response.
503 service unavailable server failed to answer due to maintenance or heavy load.
504 gateway timeout is used by a server acting as a proxy or gateway to indicate that a response cannot be obtained from a remote server in a timely manner. (HTTP 1.1 new)
505 the HTTP version not supported server does not support the HTTP version specified in the request
HTTP header details
Label:
Original address: http://www.cnblogs.com/answercard/p/4775882.html