HTTP technical documents

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
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)
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.
Range Header
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 further 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:
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 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 object header contains the original information about the object, 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"
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 only used for request messages.
Name example Value
Accept "text/html, image /*"
Accept-charset "iso8859-5"
Accept-encoding "gzip, compress"
Accept-language "en, FR"
Authorization [credentials]
Content-encoding "gzip"
Continue CT "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 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
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]
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-encoding "gzip"
Content-language "en"
Content-Length & quot; 8445 & quot"
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 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 <meta HTTP-EQUIV = "refresh" content = "5; url = http: // host/path"> 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
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, 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
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 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.
For more information about HTTP headers, see http://www.w3.org/protocols.
Appendix: Meaning of HTTP status code
Status Code status information meaning
100 the initial request for continue has been accepted, and the customer shall continue to send the rest of the request. (New HTTP 1.1)
101 The switching protocols server converts a client-compliant request to another protocol (HTTP 1.1 New
200 OK everything is normal, and the response document to the get and post requests follows.
The 201 created server has created a document and the location header provides its URL.
202 accepted has accepted the request, but the processing has not been completed.
203 the non-authoritative information document has been returned normally, but some response headers may be incorrect because the document is copied (New in HTTP 1.1 ).
204 NO content does not have a new document. The browser should continue to display the original document.
205 there is no new content in the reset content, but the browser should reset the content displayed by it. Used to force the browser to clear the input content of the form (New in HTTP 1.1 ).
206 partial content the client sent a GET request with a range header, and the server completed it (HTTP 1.1 New ).
300 the documents requested by the multiple choices client can be found in multiple locations, which are listed in the returned documents. If the server needs to give priority, it should be specified in the location response header.
301 moved permanently the document requested by the customer is elsewhere. The new URL is provided 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 permanent. Note that the status information corresponding to http1.0 is "Moved temporatily". When this status code is displayed, the browser can automatically access the new URL, so it is a useful status code. Note that this status code can be replaced with 301 sometimes. For example, if the browser mistakenly requests http: // host /~ If the user (with a slash missing), 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. The difference is that if the original request is post, the redirection target document specified by the location header should be extracted through get (New in HTTP 1.1 ).
304 The not modified client has a buffered document and issued a conditional request (generally, the IF-modified-since header is provided to indicate that the customer only wants to update the document on a specified date ). The server tells the customer that the original buffer documentation can still be used.
305 the document requested by the use proxy client should be extracted by the proxy server specified by the location header (New in HTTP 1.1 ).
307 temporary redirect and 302 (found) are the same. Many browsers mistakenly respond to the 302 response for redirection. Even if the original request is post, it can only be redirected when the POST request actually responds to 303. For this reason, HTTP 1.1 adds 307 to clear the region code in several states: When a 303 response occurs, the browser can follow the redirected get and post requests; if a 307 response occurs, the browser can only follow the redirection to get requests. (New HTTP 1.1)
400 syntax error in bad request.
401 unauthorized the customer attempted to access the password-protected page without authorization. The response contains a WWW-Authenticate header. the browser displays the username/password dialog box accordingly, and then sends a request again after entering the appropriate authorization header.
403 Forbidden resources are unavailable. The server understands the customer's request, but rejects the request. This is usually caused by permission settings for files or directories on the server.
404 Not found cannot find the resource at the specified position. This is also a common response,
405 method not allowed request methods (get, post, Head, delete, put, Trace, etc.) are not applicable to specified resources. (New HTTP 1.1)
406 the resource specified by not acceptable has been found, but its MIME type is incompatible with the one specified by the customer in the accpet header (New in HTTP 1.1 ).
407 proxy authentication required is similar to 401, indicating that the customer must first be authorized by the proxy server. (New HTTP 1.1)
408 request timeout the client has not sent any request within the waiting time permitted by the server. The customer can repeat the same request later. (New HTTP 1.1)
409 conflict is usually related to put requests. The request cannot be successful because the request conflicts with the current status of the resource. (New HTTP 1.1)
410 the document requested by gone is no longer available, and the server does not know which address to redirect. It differs from 404 in that if 407 is returned, the document permanently leaves the specified position, and 404 indicates that the document is unavailable for unknown reasons. (New HTTP 1.1)
The 411 length required server cannot process the request unless the customer sends a Content-Length header. (New HTTP 1.1)
412 precondition some of the prerequisites specified in the failed Request Header fail (New in HTTP 1.1 ).
413 the size of the target Request Entity too large document exceeds the size that the server is willing to process. If the server thinks it can process the request later, it should provide a retry-after header (New in HTTP 1.1 ).
414 request URI Too long URI is too long (HTTP 1.1 is new ).
416 the requested range not satisfiable server cannot meet the range header specified by the customer in the request. (New HTTP 1.1)
500 the internal server error server encounters unexpected circumstances and cannot complete the customer's request.
501 The not implemented server does not support the functions required to implement the request. For example, the customer sends a put request not supported by the server.
502 when the Bad Gateway server acts as a gateway or proxy, the server returns an invalid response to access the next server to complete the request.
503 the service unavailable server fails to respond due to maintenance or overload.
504 gateway timeout is used by a proxy or gateway server, indicating that the remote server cannot receive a response in a timely manner. (New HTTP 1.1)
505 the HTTP Version Not Supported server does not support the HTTP Version specified in the request. (New HTTP 1.1)

----------------------------------------------------------------------------

I personally think that as Web moves from concept to a large number of applications, network applications will become more unstoppable. I have been writing Web applications for more than two years. In the past, I mainly did some prototype systems in the school, but I have not studied the HTTP protocol in depth. Recently, the get and post methods in the HTTP request headers need to be distinguished. It takes some time to study the get and post methods. The reference is the RFC document of the HTTP protocol /~ Jkorpela/Forms/methods.html.
Anyone with experience in network compilation knows that get and Ppost can be used in form method. As for what occasions should I use, I have not carefully considered it myself, and I am always interested in it.
What are the essential differences between get and post?
Use get and form to encode the data in the URL, and use post form to transmit the data in the HTTP header. In terms of use, get is used only when the request idempotence (literally, the request returns the same result at any time, essentially the request itself does not change the server data and status, when the request changes the server data or status (update data, upload files), you should use post.
What is the difference between get and post?
When you repeatedly access the page requested by the get method, the browser uses the cache to process subsequent requests. When a form is submitted using the POST method, the browser opportunity post will generate a permanent change assumption, and the user will be asked to submit for confirmation. When the compiled personnel correctly use get and post, the browser will provide good cache cooperation, and the response speed is faster.
Differences in Form submission
The first step of Form submission is to create a dataset and encode the dataset according to enctype. Enctype has two values: multipart/form-data, application/X-WWW-form-urlencoded (default value). The former can be used for both get and post, and the latter only for post. Then perform data transmission-for the get method, the dataset is encoded using content type application/X-WWW-form-urlencoded and attached to the URL. In this mode, the data is strictly limited to ASCII code; for post, use the content type encoding Character Set and construct it into message sending.
Differences in server processing
In principle, there is no difference in processing get and post requests. However, because data is encoded using different methods, different decoding mechanisms are required. Therefore, method changes will lead to code changes for processing requests. For example, for CGI, parameters are obtained through environment variables during get processing, and data is obtained through standard input (stdin) When POST requests are processed.

From the usage experience, we will summarize the following:
1. Get adds the parameter data queue to the URL referred to by the Action attribute of the submission form. The values correspond to each field in the form one by one and can be seen in the URL. Post uses the http post mechanism to place fields in the form and their content in the HTML header and send them to the URL address referred to by the Action attribute. You cannot see this process.
2. For the get method, the server uses request. querystring to obtain the value of the variable. For the POST method, the server uses request. Form to obtain the submitted data. You can use request to obtain parameters in either of the two methods.
3. The data volume transmitted by get is small and cannot exceed 2 kb. The amount of data transmitted by post is large, which is generally not restricted by default. Theoretically, the maximum size of IIS4 is 80 KB, and that of iis5 is 100kb.
4. Low get security and high post security.
5. <form method = "get" Action = "A. asp? B = B "> with <form method =" get "Action =". ASP "> is the same. That is to say, the parameter list behind the action page is ignored, while <form method =" Post "Action =". asp? B = B "> unlike <form method =" Post "Action =" A. asp ">.