HTTP response message Structure

The HTTP response message consists of three parts: Response line, response header, and response body.

First, Response Line: protocol version + status code + description

Common Status Codes:

100-199: Indicates a successful receive request that requires the client to continue submitting the next request in order to complete the process.

200-299: Indicates a successful receive request and has completed the entire process, commonly used 200

300-399: In order to complete the request, the customer needs to further refine the request. For example: The requested resource has moved a new address, common 302 (meaning you ask me, I ask you to find someone else), 307 and 304 (I do not give you this resource, take the cache yourself)

400-499: Client request has error, common 404 (means that the resource you requested is not in the Web server) 403 (server denied access, insufficient permissions)

500-599: Error on server side, common 500

Second, the response head

The response header is used to describe the basic information of the server, as well as the description of the data, the server through the description of the data Venus Show, you can tell the client how to deal with the data after a while it loopback.

Setting the HTTP response header is often combined with the status code. For example, there are several states where the "document position has changed" status code is accompanied by a location header, while the 401 (unauthorized) status code must be accompanied by a www-authenticate header. However, it is also useful to specify the answer header even when no special meaning is set for the status code. The answer header can be used to complete: Set a cookie, specify a modification date, instruct the browser to refresh the page at a specified interval, declare the length of the document to take advantage of persistent HTTP connections, and many other tasks.

The common response header field meaning:

Allow: Which request methods are supported by the server (such as GET, post, etc.)

Content-encoding: The Encoding (Encode) method of the document. The content type specified by the Content-type header can be obtained only after decoding. Using gzip to compress documents can significantly reduce the download time of HTML documents. Java's gzipoutputstream can be easily gzip compressed, but only Netscape on Unix and IE4 on Windows, IE5 support it. Therefore, the servlet should check whether the browser supports gzip by looking at the accept-encoding header (that is, Request.getheader ("accept-encoding")). Returns the gzip-compressed HTML page for a browser that supports gzip, returning a normal page for another browser.

Content-length: Indicates the content length. This data is only required if the browser is using a persistent HTTP connection. If you want to take advantage of the persistent connection, you can write the output document to Bytearrayoutputstream, look at its size when done, then put that value into the Content-length header and finally pass the Bytearraystream.writeto ( Response.getoutputstream ()) to send content.

Content-type: Indicates what MIME type the following document belongs to. The servlet defaults to Text/plain, but usually needs to be specified as text/html. Because Content-type is often set up, HttpServletResponse provides a dedicated method setContentType.

Date: The current GMT time, for example, Date:mon,31dec200104:25:57gmt. The time described by date represents the world standard, which translates into local time and needs to know the time zone in which the user is located. You can use Setdateheader to set this header to avoid the hassle of converting the time format.

Expires: Tells the browser how long it takes to cache the loopback resource, 1 or 0 is not cached.

Last-modified: The last time the document was changed. The customer can provide a date through the If-modified-since request header, which is treated as a conditional get, and only documents that have been modified later than the specified time are returned, otherwise a 304 (not Modified) state is returned. Last-modified can also be set using the Setdateheader method.

Location: This header is used with the 302 status code to redirect the recipient to a new URL address. Indicates where the customer should go to extract the document. Location is not usually set directly, but by HttpServletResponse's Sendredirect method, which sets the status code to 302

Refresh: Tell the browser how often it is refreshed, in seconds.

Server: This header tells the browser the type of server. The server response header contains software information for the originating server that processed the request. This field can contain multiple product identifiers and annotations, and product identities are generally sorted by importance. The servlet generally does not set this value, but is set by the Web server itself.

Set-cookie: Sets the Cookie associated with the page. The servlet should not use Response.setheader ("Set-cookie",...), but should use the dedicated method Addcookie provided by HttpServletResponse.

Transfer-encoding: Tells the browser the transfer format of the data.

Www-authenticate: What type of authorization information should the customer provide in the authorization header? This header is required in an answer that contains a 401 (unauthorized) status line. For example, Response.setheader ("Www-authenticate", "BASIC realm=\" Executives\ ""). Note that servlets generally do not handle this, but instead let the Web server's specialized agencies control access to password-protected pages.

Note: The most common method for setting up the answer header is the setheader of HttpServletResponse, which has two parameters that represent the name and value of the answer header, respectively. Similar to setting the status code, the setup answer header should be done before any document content is sent.

The Setdateheader method and the Setintheadr method are specifically designed to set up an answer header that contains a date and integer value, which avoids the hassle of converting Java time to a GMT time string, which avoids the hassle of converting integers to strings.

HttpServletResponse also offers a number of settings:

1.setContentType: Set Content-type header. This method is used by most servlets.

2.setContentLength: Set Content-length header. This function is useful for browsers that support persistent HTTP connections.

3.addCookie: Set a cookie (there is no Setcookie method in the Servlet API, because the answer often contains multiple Set-cookie headers).

Third, the response body

The response body is the message body of the response, if the pure data is the return of pure data, if the request is an HTML page, then the HTML code is returned, if it is JS is the JS code, and so on.

The HTTP response message format is as shown

The header fields of HTTP include universal headers, request headers, response headers, and entity headers.

1. General Header Domain

The generic header domain contains header domains that both request and response messages support, and the generic header domain contains Cache-control, Connection, Date, Pragma, transfer-encoding, Upgramde, Via. The expansion of the universal header domain requires both parties to support this extension, and if there is an unsupported universal header domain, it will generally be handled as the entity header domain. The following is a brief introduction to several common header fields:

　　　

Cache-control: Specifies the caching mechanism that requests and responses follow.

Setting Cache-control in a request message or response message does not modify the caching process in another message processing process. The cache directives for the request include No-cache, No-store, Max-age, Max-stale, Min-fresh, only-if-cached, and the instructions in the response message include public, private, No-cache, No-store, No-transform, Must-revalidate, Proxy-revalidate, Max-age. The instructions in each message have the following meanings:

~ ~ Public indicates that the response can be cached by any buffer.

~ ~ Private indicates that the entire or partial response message for a single user cannot be shared cache processing. This allows the server to simply describe a partial response message for the user, and this response message is not valid for another user's request.

~ ~ No-cache indicates that the request or response cannot be cached

~ ~ No-store is used to prevent the inadvertent release of important information. Sending in the request message will make the request and response messages not use the cache.

~ ~ Max-age indicates that the client can receive a response that is not longer than the specified time (in seconds).

~ ~ Mix-fresh indicates that the client can receive response times that are less than the current time plus the specified time.

~ ~ Max-stale indicates that the client can receive a response message beyond the timeout period. If you specify a value for the Max-stale message, the client can receive a response message that exceeds the specified value for the timeout period.

~ ~ Date: Indicates when the message was sent, and the time description format was defined by rfc882. For example, Date:mon,31dec200104:25:57gtm. The time described by date represents the world standard, which translates into local time and needs to know the time zone in which the user is located.

~ ~ Pragma: Used to include implementation-specific instructions, the most commonly used is pragma:no-cache. In the http/1.1 protocol, it has the same meaning as Cache-control:no-cache.

　　

2. entity header Field

Both the request message and the response message can contain entity information, which generally consists of entity header fields and entities. 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 a coded stream of bytes encoded by content-encoding and Content-type, whose length is defined by content-length or Content-range.

Common Entity Header meanings:

Content-encoding: The server tells the browser the compression format of the data through this header.

Content-length: The server tells the browser the length of the loopback data through this header.

Content-dispositon: tells the browser to open the data in the download mode.

Content-type: The server tells the browser the type of the loopback data through this header. The Content-type entity header is used to indicate the media type of the entity to the receiver, specify the entity media type that the head method sends to the receiver, or the request media type sent by the Get method.

Content-range: Used to specify the insertion position of a part of an entire entity, and he also indicates the length of the entire entity. When the server returns a partial response to the customer, it must describe the extent of the response coverage and the entire length of the entity. General format:

Content-range:bytes-unitspfirst-byte-pos-last-byte-pos/entiy-legth

For example, the transfer header is in the form of a 500-byte secondary field: content-range:bytes0-499/1234, if an HTTP message contains this section (for example, a response to a range request or a range of overlapping requests), Content-range represents the range of the transfer, The content-length represents the number of bytes actually transferred.

Last-modified: Specifies that the last revision of the saved content on the server is actual.

ETag: Caches the associated headers.

Expires: tells the browser to cache the loopback resource for a long time 1 or 0 is not cached

　　

There are three types of header fields that prohibit browser caching:

Expires:-1 or 0

Cache-control:no-cache

Pragma:no-cache

GET, Post differences

　　HTTP defines different ways to interact with the server, with 4 basic methods: GET, POST, PUT, DELETE.

And the Get, POST, PUT, delete in HTTP corresponds to the search, change, increment and delete of the URL resource 4 operations. So, get is generally used to get/query resource information, and post is typically used to update resource information.

The main distinction between get and post

1. Form of submission of data:

The data of the GET request is appended to the URL (that is, the data is placed in the HTTP protocol header) and is directly displayed in the Address bar. Split the URL and transfer the data, the parameters are connected with &, such as: Login.action?name=hyddd&password=idontknow&verify=%e4%bd%a0%e5%A5%BD.

If the data is an English letter/number, sent as is, if it is a space, converted to +, if it is Chinese/other characters, the string is directly encrypted with BASE64, such as:%e4%bd%a0%e5%a5%bd, where the xx in%xx is the symbol in 16 binary notation ASCII.

The Post method places the data in the Request data field & separates the fields, the request row does not contain data parameters, and the address bar does not have additional parameters

2. Size of submission Data

The size of the Get method commit data directly affects the length of the URL, but the HTTP protocol specification is in fact not the URL limit length, the limit URL length is the client or server support different influence: for example, ie on the URL length limit is 2083 bytes (2k+35). For other browsers, such as Netscape, Firefox, etc., there is theoretically no length limit, and its limitations depend on the support of the operating system.

The post-mode HTTP protocol specification also has no qualification, which limits the processing power of the server's handlers.

So the size limit is still affected by the various Web server configurations.

3. Security of submitted data

Post is more secure than get mode

By using get to submit data, the user name and password will appear in plaintext on the URL, because for a few reasons get way security will be weaker than post:

(1) The login page may be cached by the browser

(2) Other people view the history of the browser, then others can get your account number and password.

(3) The security performance is worse when a cross-site attack is encountered.

HTTP response message Structure