Dig into the use of HTTP head

HTTP (HyperTextTransferProtocol) is short for hypertext transfer protocol. It is used to transmit data in WWW mode. Please refer to RFC2616 for details of HTTP protocol. The HTTP protocol USES the request/response model. The client sends a request to the server with the request header containing the method of the request, URI, protocol version, and an MIME-like message structure containing the request modifier, customer information, and content. The server responds with a status line that includes the version of the message protocol, the success or error encoding, plus the server information, entity meta-information, and possible entity content.

Typically, HTTP messages include a request message from the client to the server and a response message from the server to the client. These two types of messages consist of one starting line, one or more header fields, one empty line that is just the end of the header field, and an optional message body. The header field of HTTP consists of four parts: the generic header, the request header, the response header, and the entity header. Each header field consists of a domain name, a colon (:), and a field value of three parts. The domain name is case-insensitive, and any number of Spaces can be added before the field value. The header field can be extended to multiple lines, with at least one space or TAB at the beginning of each line.  
Generic header field  
The generic header field contains the header fields that are supported for both request and response messages, and the generic header field includes Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade, Via. Extensions to generic header fields are supported by both parties in the communication. If there is an unsupported generic header field, general 1 will be treated as an entity header field. Here is a brief overview of some common header fields used in UPnP messages.  
  Cache - Control head 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 the other message processing. Cache instructions at request time include no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached, The commands 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 meaning:  
Public indicates that the response can be cached by any cache.  
Private indicates that the entire or part of the response message for a single user cannot be processed by the Shared cache. This allows the server to only describe a partial response message when a user, which is not valid for a request from another user.  
no-cache indicates that the request or response message cannot cache  
no-store is used to prevent important information from being inadvertently released. Sending in a request message will take both the request and response messages out of cache.  
max-age indicates that a 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 with a response time 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 the value of the max-stale message, the client can receive the response message beyond the specified value in the timeout.  
  Date head domain
The Date header field represents the time at which the message was sent, and the time description format is defined by rfc822. For example, Date: Mon, 31 Dec200104:25:57 GMT. The time described by Date represents the world standard time, the conversion cost of local time, need to know the user's time zone.  
  Pragma head domain
The Pragma header field is used to contain implementation specific instructions, most commonly Pragma: no-cache. In the HTTP/1.1 protocol, it has the same meaning as Cache-Control: no-cache.  
Request message  
The following format for the first action of the request message:  
MethodSPRequest-URISPHTTP-VersionCRLFMethod represents the method completed by Request-URI, and this field is case-sensitive, including OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE. Methods GET and HEAD should be supported by all common WEB servers, and all other method implementations are optional. The GET method retrieves the information identified by Request-URI. The HEAD method also retrieves the information identified by Request-URI, except that it can respond without returning the body of the message. The POST method can request the server to receive entity information contained in the request and can be used to submit forms and send messages to newsgroups, BBS, mail groups, and databases.

SP stands for space. Request-URI follows the URI format, and when this field is an asterisk (*), it indicates that the request is not for a particular resource address, but for the server itself. HTTP-Version represents the supported version of HTTP, for example, HTTP/1.1. CRLF stands for newline carriage return. The request header domain allows the client to pass additional information to the server about the request or about the client. The request header field may contain 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 Both sides of the request communication support the request header domain extension. If there is an unsupported request header domain, 1 will be treated as the entity header domain.  
Typical request message:  
GET http://download.microtool.de:80/somedata.exe  
Host: download.microtool.de  
Accept:*/*  
Pragma: no-cache  
Cache-Control: no-cache  
Referer: http://download.microtool.de/  
User-Agent:Mozilla/4.04[en](Win95;I;Nav)  
Range:bytes=554554-  
Line 1 of the above example indicates that the HTTP client (possibly the browser, the download program) gets the file under the specified URL via the GET method. The brown section represents the information for the request header field, and the green section represents the generic header section.  
  Host head domain
The Host header domain specifies the Intenet host and port number for the requested resource and must represent the location of the original server or gateway for the requested url. The HTTP/1.1 request must contain the host header domain, otherwise the system will return as a 400 status code.  
  Referer head domain
The Referer header domain allows the client to specify the source resource address for requesting uri, which allows the server to generate a fallback list that can be used to log in, optimize cache, and so on. It also allows for disabled or faulty connections to be tracked for maintenance purposes. If the requested uri does not have its own uri address, Referer cannot be sent. If the partial uri address is specified, the address should be a relative address.  
  Range head domain
The Range header domain can request one or more subscopes of an entity. For example,  
Represents the first 500 bytes: bytes=0-499  
Represents the second 500 byte: bytes=500-999  
Represents the last 500 bytes: bytes=-500  
Represents the range after 500 bytes: bytes= 500- 
The first and last byte: bytes=0-0,-1  
Specify several ranges at the same time: bytes=500-600,601-999  
However, the server can ignore this request header, and if the unconditional GET contains the Range request header, the response will be returned as a status code 206 (PartialContent) instead of 200 (OK).  
  User - Agent head domain
The content of the User-Agent header field contains the requested user information.  
Response message  
The following format for the first action of the response message:  
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF  
HTTP-Version represents the supported version of HTTP, for example, HTTP/1.1. Status- Code is a 3 digit result code. Reason-Phrase gives Status-Code a simple text description. Status-Code is mainly used for automatic machine recognition, and Reason-Phrase is mainly used to help users understand. The first number of Status-Code defines the category of the response. The last two Numbers do not have the function of classification. The first number may have five different values:  
1xx: the message response class that receives the request and continues processing  
2xx: handles the successful response class, indicating that the action was successfully received, understood, and accepted by  
3xx: the redirected response class, which must accept   in one step in order to complete the specified action
4xx: client error, client request contains syntax error or failure to execute   correctly
5xx: server error, the server cannot correctly execute 1 correct request  
The response header fields allow the server to pass additional information that cannot be placed on the status line. These fields primarily describe the server's information and the Request-URI advanced information. The response header fields include Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning, WWW-Authenticate. Both sides of the communication support the extension of response header fields. If there are unsupported response header fields, 1 will be treated as entity header fields.  
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  
Line 1 of the above example shows the HTTP server responding to an GET method. The brown part represents the information of the response header field, the green part represents the generic 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 software information about the original server that processed the request. This field can contain multiple product identifiers and comments, product identifiers 1 as in order of importance.  
Entity  
Both the request and response messages can contain entity information, and entity information 1 generally consists of entity header fields and entities. The entity header field contains the original information about the entity, The entity heads include Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Type, Etag, Expires, Last-Modified, extension-header, extension-header, extension-header. extension-header allows clients to define new entity headers, but these domains may not be recognized by the non-recipient. An entity can be a encoded byte stream, encoded in a manner defined by Content-Encoding or Content-Type, and its length defined by Content-Length or Content-Range.  
Content-Type solid header  
The Content-Type entity header is used to indicate the entity's media type to the receiver, specifying the entity media type to which the HEAD method is sent to the receiver, or the requested media type Content-Range entity header   to which the GET method is sent
The Content-Range entity header is used to specify the insertion location of part 1 of the entire entity, which also indicates the length of the entire entity. When the server returns a partial response to the client, it must describe the extent of the response coverage and the overall entity length. General format:  
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth  
For example, if an Content-Range message contains this section (for example, a response to a range request or an overlapping request to a range of 1 series), Content-Range represents the range of the transmission, and Content-Length represents the number of bytes actually transmitted.  
Last-modified solid head  
The Last-modified entity header specifies the last revision time the content was saved on the server.

Reply head aaaaaaaaaaaaaaaaaaaaaaaaa instructions Allow Which request methods are supported by the server (e.g., GET, POST, etc.). Content-Encoding Document encoding (Encode) method. The content type specified by the Content-Type header is available only after decoding. Compression of gzip documents can significantly reduce the download time of HTML documents. Java's GZIPOutputStream is very convenient for gzip compression, but it is only supported by Netscape on Unix and IE 4, IE 5 on Windows. Therefore, Servlet should check that the browser supports gzip by viewing the Accept-Encoding header (request.getHeader (" Accept-Encoding "), return HTML compressed gzip pages for gzip supported browsers, and return normal pages for other browsers. Content-Length Is the length of the content. This data is only required if the browser is using a persistent HTTP connection. If you want to take advantage of persistent connections, you can write the output document to ByteArrayOutputStram, check its size when you're done, put the value into the Content-Length header, and send the content via byteArrayStream.writeTo (response.getOutputStream ()). Content-Type Indicates what type MIME the following document belongs to. Servlet defaults to text/plain, but you usually need to explicitly specify text/html. Since Content-Type is often set, HttpServletResponse provides a dedicated method, setContentTyep.   Date Current GMT time. You can set this header using setDateHeader to avoid the hassle of converting the time format. Expires At what point should a document be considered expired and not cached? Last-Modified The last time the document was changed. The client can provide a date through the If-Modified-Since request header. This request will be treated as a condition GET and will only be returned if the change is later than the specified time. Otherwise, a 304 (Not Modified) status will be returned. Last-Modified can also be set using the setDateHeader method. Location Represents where the customer should go to extract the document. Location is usually not set directly, but via sendRedirect's HttpServletResponse method, which also sets the status code to 302. Refresh Indicates how much time the browser should refresh the document after, in seconds. In addition to refreshing the current document, you can also use setHeader("Refresh", "5 "; URL = http: / / host path ") the browser reads the specified page.  
Note that this is usually done by setting the HTML page HEAD area < META HTTP-EQUIV ="Refresh" CONTENT="5 "; URL = http: / / host path "> implementation, this is because the automatic refresh or redirect those unable to use CGI or Servlet HTML writers 10 points. However, for Servlet, 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". Thus, a continuous refresh requires that one Refresh header be sent at a time, and a 204 status code be sent to 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 1 of the formal HTTP 1.1 specification, but is an extension, though it is supported by both Netscape and IE. Server Server name. Servlet1 normally does not set this value, but is set by the Web server itself. Set-Cookie Set the Cookie associated with the page. Servlet should not use response.setHeader(" Set-Cookie ",...) Instead, use the dedicated method addCookie provided by HttpServletResponse. See below for a discussion of the Cookie setup. WWW-Authenticate What type of authorization information should the customer provide in the Authorization header? This header is required in the response containing the 401 (Unauthorized) status line. For example, response.setHeader (" WWW-Authenticate ", "BASIC realm= \ "executives \ "").  
Note that Servlet1 generally does not do this, but instead lets the Web server's specialized mechanism control access to password-protected pages (for example.htaccess).