Technical information about http headers in http
HyperTextTransferProtocol is short for Hypertext Transfer Protocol. It is used to transmit WWW Data. For details about HTTP, see rfc2616. The HTTP protocol uses the request/response model. The client sends a request to the server. The request header contains the request method, URI, Protocol version, and message structure similar to MIME 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, and the server information, entity metadata, and possible entity content are added to the success or error code.
Generally, HTTP messages include the request message sent from the client to the server and the response message sent from the server to the client. These two types of messages are composed of a starting line, one or more header fields, an empty line that is only the end of the header field, and an optional message body. The HTTP header includes four parts: Common headers, request headers, response headers, and object headers. Each header field consists of a domain name, a colon (:), and a domain value. The domain name is case-insensitive. You can add any number of space characters before the Domain value. The header field can be expanded to multiple rows. At least one space or Tab character is used at the beginning of each line.
1. General header domain
The general header domain includes the header domains supported by both request and response messages. The general header domain includes Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade, and. The extension of the common header domain requires both parties to support this extension. If a common header domain is not supported, it is generally processed as the object header domain. The following describes some general header fields used in UPnP messages.
Cache-Control header field
Cache-Control specifies the Cache mechanism that requests and responses follow. Setting Cache-Control in a request message or response message does not modify the Cache processing process of another message. The cache commands in the request include no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached, commands in the Response Message include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, and max-age. The instructions in each message are as follows:
Public indicates that the response can be cached in any cache area.
Private indicates that the whole or part of the response message of a single user cannot be processed by the shared cache. This allows the server to only describe part of the user's response message, which is invalid for requests of other users.
No-cache indicates that the request or response message cannot be cached.
No-store is used to prevent the unintentional release of important information. Sending a request message does not cache the request and response messages.
Max-age indicates that the client can receive responses with a lifetime not greater than the specified time (in seconds.
Min-fresh indicates that the client can receive a response whose response time is earlier than the current time plus the specified time.
Max-stale indicates that the client can receive response messages beyond the timeout period. If the value of the max-stale message is specified, the client can receive response messages that exceed the timeout period.
Date header field
The Date header field indicates the message sending time. The description format of the time is defined by rfc822. For example, Date: Mon, 31Dec200104: 25: 57GMT. The time described in Date indicates the world standard time. You need to know the time zone of the user to convert the local time.
Pragma header domain
The Pragma header field is used to contain specific instructions. The most common method is Pragma: no-cache. The meaning of HTTP/1.1 is the same as that of Cache-Control: no-cache.
2. Request Message
The format of the first action of the request message is as follows:
Method SP request-Uri SP http-version CRLF
Method indicates the method for completing request-Uri. This field is case sensitive, including options, get, Head, post, put, delete, and trace. Methods get and head should be supported by all common Web servers, and implementation of all other methods is optional. The get method retrieves the information identified by request-Uri. The head method also retrieves the information identified by request-Uri, but does not return the message body during the response. The post method can request the server to receive entity information contained in the request. It can be used to submit forms and send messages to newsgroups, BBS, contact groups, and databases.
SP indicates space.
Request-Uri follows the URI format. When this field is asterisk (*), 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 indicates a line feed.
The request header field allows the client to transmit request or additional information about the client to the server. The request header field may contain the following fields: Accept, accept-charset, accept-encoding, accept-language, authorization, from, host, if-modified-since, if-match, and if-none. -match, if-range, if-range, if-unmodified-since, Max-forwards, proxy-authorization, range, Referer, and User-Agent. Both parties need to support the expansion of the Request Header domain. If an unsupported Request Header domain exists, it is generally processed as an object header domain.
Typical request message:
Gethttp: // class/download.microtool.de: 80/somedata.exe
Referer: http: // class/download.microtool.de/
User-Agent: Mozilla/4.04 [en] (Win95; I; Nav)
Value Range: bytes = 554554-
In the preceding example, the first line indicates that the HTTP client (which may be a browser or a download program) obtains the file under the specified URL through the GET method. The brown part indicates the information of the request header field, and the green part indicates the general header part.
Host Header domain
The Host Header specifies the Intenet Host and port number of the requested resource, which must represent the location of the original server or gateway of the request url. The HTTP/1.1 request must contain the Host Header domain; otherwise, the system returns the status code 400.
Referer header field
The Referer header field allows the client to specify the source resource address of the request uri, which allows the server to generate a rollback linked list for login and cache Optimization. He also allows abolished or erroneous connections to be tracked for maintenance purposes. If the requested uri does not have its own uri address, the Referer cannot be sent. If some uri addresses are specified, this address is a relative address.
The Range header field can request one or more sub-ranges of an object. 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 the following ranges: bytes = 500-600,601-999.
However, the server can ignore this 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 contains the User information that sends the request.
3. Response Message
The format of the first response message is as follows:
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP-Version indicates the supported HTTP Version. For example, HTTP/1.1.
Status-Code is the result Code of three numbers.
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 digit of Status-Code defines the category of the response. The last two digits do not have a category. The first number may have 5 different values:
1xx: Information Response class, indicating that the request is received and processed continuously
2xx: Successful response class, indicating that the action is successfully received, understood, and accepted
3xx: redirect response class. To complete the specified action, you must accept further processing.
4xx: client error. The client request contains a syntax error or cannot be correctly executed.
5xx: server error. The server cannot correctly execute a correct request.
The response header field allows the server to transmit additional information that cannot be placed in the status line. These fields mainly describe the server information and Request-URI information. The Response Header includes Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning, and WWW-Authenticate. The expansion of the Response Header domain requires both parties to support the communication. If an unsupported Response Header domain exists, it is generally processed as an entity header domain.
Typical response message:
Date: Mon, 31Dec200104: 25: 57GMT
Server: Apache/1.3.14 (Unix)
Last-modified: Tue, 17Apr200106: 46: 28GMT
Etag: "a030f020ac7c01: 1e9f"
The first line in the preceding example indicates that the HTTP server responds to a GET method. The brown part indicates the information of the response header field, the green part indicates the general header part, and the red part indicates the information of the object 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 processes the request. This domain can contain multiple product identifiers and comments. Product identifiers are generally sorted by importance.
4. entity information
Request messages and response messages can both contain entity information. entity information is generally composed of entity header fields and entities. The entity header contains the original information about the entity, object headers include Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Etag, Expires, Last -Modified and extension-header. Extension-header allows the client to define new object headers, but these fields may not be recognized by the recipient. An object can be an encoded byte stream. Its Encoding method is defined by Content-Encoding or Content-Type. Its Length is defined by Content-Length or Content-Range.
Content-Type object header
The Content-Type object header is used to indicate the media Type of the object to the receiver, specify the object media Type sent by the HEAD Method to the receiver, or request media Type Content-Range object header sent by the GET method.
Content-Range Object Header
Specifies the insert position of a part of the entire object, which also indicates the length of the entire object. When the server returns a partial response to the customer, it must describe the response coverage and the length of the entire object. General format:
Content-Range: bytes-unit SP first-byte-pos-last-byte-pos/entity-Lety
For example, transfer the form of the header 500 byte field: Content-Range: bytes0-499/1234 if an http message contains this section (for example, content-Range indicates the transfer Range, and Content-Length indicates the number of bytes actually transmitted.
Last-modified Object Header
The Last-modified object header specifies the Last revision time of the content saved on the server.
5. HTTP header reference (microsoft)
Both HTTP requests and HTTP responses use headers to send information about HTTP messages. The header is composed of a series of rows, each line contains a name, followed by a colon, space, and 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 the client to specify multiple acceptable options in the value section, and sometimes even rank the preference of these options. Multiple items are separated by commas. For example, a client can send a request header containing "Content-Encoding: gzip, compress," to accept various compression types. If the response body of the server uses gzip Encoding, the response header will contain "Content-Encoding: gzip ".
Some fields can appear multiple times in a single header. For example, the 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 RFC 2045 of the Internet Engineering Task Force (IETF) documentation, but can also be used for HTTP 1.1. For more information about MIME and HTTP 1.1 specifications, see the IEIF page.
General header field
Common header fields can be used for request messages and response messages.
Name example Value
Cache-Control "max-age = 10"
Date "Tue, 11 Jul 2000 18:23:51 GMT"
Via "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning "112 Disconnected Operation"
Request Header field
The request header field is only used for request messages.
Name example Value
Accept "text/html, image /*"
Accept-Encoding "gzip, compress"
Accept-Language "en, fr"
Continue CT "100-continue"
Host "http://www.microsoft.com /"
If-Modified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
If-Range "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
Range "bytes = 100-599"
User-Agent "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0 )"
> Specific meanings of request header fields
Accept: the MIME type acceptable to the browser.
Accept-Charset: the acceptable character set of the browser.
Accept-Encoding: The data Encoding method that the browser can decode, such as gzip.
Accept-Language: the type of Language that the browser wants to use when the server can provide more than one Language version.
Authorization: Authorization information, usually displayed 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 the request uses HTTP 1.1 (HTTP 1.1 performs a persistent connection by default), it can take advantage of the advantages of persistent connections, when a page contains multiple elements (such as an Applet or image), the download time is significantly reduced. To achieve this, the Servlet needs to send a Content-Length header in the response. The simplest method is to write the Content into ByteArrayOutputStream first, then, calculate the size of the content before writing it.
Content-Length: the length of the Request Message Body.
COOKIE: set the cookie. This is one of the most important request header information.
From: the e-mail address of the Request sender, which is used by some special Web client programs and not used by the browser.
HOST: host and port in the initial URL.
If-modified-since: it is returned only when the requested content is modified after the specified date. Otherwise, the 304 "not modified" response is returned.
Pragma: specifying the "no-Cache" value indicates 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 you can access the current requested page.
User-Agent: browser type. This value is useful if the content returned by the servlet is related to the browser type.
UA-pixels, UA-color, UA-OS, UA-CPU: non-standard request headers sent by some versions of IE, indicating screen size, color depth, operating system, and cputype.
Response Header field
The response header field is only used to respond to messages.
Name example Value
Age "2147483648 (2 ^ 31 )"
Last-modified "Tue, 11 Jul 2000 18:23:51 GMT"
Location "http: // localhost/redirecttarget. asp"
Retry-After "Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Object header field
The object header field can be used to request or respond to a message. The entity header field contains information about the message entity body, such as the encoding format used.
Name example Value
Allow "GET, HEAD"
Content-Length & quot; 8445 & quot"
Content-Location "http: // localhost/page. asp"
Content-Range "bytes 2543-4532/7898"
Expires "Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified "Tue, 11 Jul 2000 18:23:51 GMT"
> Specific meanings of object header fields
Which request methods (such as GET and POST) are supported by the Allow server ).
The Encoding (Encode) method of the Content-Encoding document. The Content Type specified by the Content-Type header can be obtained only after decoding. Gzip compression can significantly reduce the download time of HTML documents. Java GZIPOutputStream can be easily compressed by gzip, but it is supported only by Netscape on Unix and IE 4 and IE 5 on Windows.
Content-Length indicates the Content Length. This data is required only when the browser uses a persistent HTTP connection.
Content-Type indicates the MIME Type of the subsequent document. Servlet is text/plain by default, but it must be explicitly specified as text/html.
The current GMT time of Date. You can use setDateHeader to set this header to avoid the trouble of converting the time format.
When should Expires consider that the document has expired and thus it is no longer cached?
The Last modification time of the Last-Modified document. You can use the If-Modified-Since request header to provide a date. This request is considered as a condition GET. Only documents whose modification time is later than the specified time will be returned, otherwise, a 304 (Not Modified) status is returned.
Location indicates where the customer should extract the document. Location is usually not set directly, but through the sendRedirect method of HttpServletResponse. This method also sets the status code to 302.
Refresh indicates the time after which the browser should Refresh the document, in seconds. In addition to refreshing the current document, you can also use setHeader ("Refresh", "5; URL = http: // host/path") to allow the browser to read the specified page.
Note that this feature is typically implemented by setting the <META HTTP-EQUIV = "Refresh" C> In the HEAD area of the HTML page, because, automatic refresh or redirection is important for HTML writers who cannot use CGI or Servlet. However, for Servlet, it is more convenient to directly set the Refresh header.
Note that Refresh indicates "Refresh the page after N seconds or access the specified page", rather than "Refresh the page or access the specified page every N seconds ". Therefore, continuous refreshing requires that a Refresh header be sent each time, and sending the 204 status code can prevent the browser from refreshing, whether it's using the Refresh header or <META HTTP-EQUIV = "Refresh"...>.
Note that the Refresh header is not part of the official HTTP 1.1 Specification but an extension, but is supported by both Netscape and IE.
Request Header example
The following is a simple example of an HTTP request.
GET/articles/news/today. asp HTTP/1.1
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, including the method (GET), Resource path (/articles/news/today. asp), and HTTP Version (HTTP/1.1 ). Because the request has no body, the content after all request lines is part of the header. The header is followed by an empty line, indicating that the header has ended.
Response Header example
The Web server can respond to the previous request in multiple ways. If the object is accessible and the user has the permission to view the object, the response is similar:
HTTP/1.1 200 OK
Server: Microsoft-Microsoft IIS/5.0
Date: Thu, 13 Jul 2000 05:46:53 GMT
Set-Cookie: ASPSESSIONIDQQGGGNCG = LKLDFFKCINFLDMFHCBCBMFLJ; path =/
The first line of the response is called the status line. It contains the HTTP Version, status code (200), and cause phrase used for the response. The example contains a header with five fields, followed by an empty line (carriage return and line break), followed by the first two lines of the response body.