http

192.168.188.8 - - [13/Dec/2012:01:21:15 +0000] "GET /" 302 193 "-" "-"

The HTTP response status code 302 Found is a common way of performing a redirection.

An HTTP response with this status code will additionally provide a URL in the Location header field. The User Agent (e.g. a web browser) is invited by a response with this code to make a second, otherwise identical, request, to the new URL specified in the Location field. The HTTP/1.0 specification (RFC 1945) defines this code, and gives it the description phrase "Moved Temporarily".

Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g.POST). ^[1] For this reason, HTTP/1.1 (RFC 2616) added the new status codes 303 and 307 to disambiguate between the two behaviours, with 303 mandating the change of request type to GET, and 307 preserving the request type as originally sent. Despite the greater clarity provided by this disambiguation, the 302 code is still employed in web frameworks to preserve compatibility with browsers that do not implement the HTTP/1.1 specification. ^[2]

[edit]Example

Client request:

GET /index.html HTTP/1.1
Host: www.example.com

Server response:

HTTP/1.1 302 Found
Location: http://www.iana.org/domains/example/

回车(\r, return, CR, Carriage Return) 换行(\n, newline, LF, Line Feed) CR, LF, CR/LF是不同操作系统上使用的换行符

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

Overview of HTTP health monitor request formatting for the BIG-IP GTM system

The BIG-IP GTM HTTP and HTTPS application health monitors can be used to verify the health of the server by checking whether the expected response is returned in response to a specific request. The following information is intended to help you construct an appropriate request to verify the health of your HTTP servers.
Description
By default, the BIG-IP GTM system uses HTTP version 0.9 when sending monitor requests. An HTTP version 0.9 request consists of only a request line, which must be terminated by a line feed (LF) character. The request line consists of a single line containing the HTTP request method, a space, and the name of the object requested (including the path, if necessary). No version is specified. No headers or request body are supported in HTTP 0.9. The official HTTP 0.9 specification included only one request method: GET. An example of an HTTP version 0.9 GET request may appear similar to the following example:
GET /index.html
By specifying the HTTP version in the Send String, you can force the BIG-IP GTM system to send an HTTP version 1.0 or 1.1 request that accommodates a wider range of request options. An HTTP version 1.0 or 1.1 request begins with a request line that consists of a single line containing the HTTP request method, a space, the name of the object requested (including the path, if necessary), a space, and the HTTP version of the request. The request line may be followed by a list of headers. The request line and each header line in an HTTP version 1.0 or 1.1 request must be terminated with a single carriage return / line feed (CR/LF) sequence, and the end of the request headers is indicated by a terminating double carriage return / line feed sequence (CR/LF/CR/LF). For some request methods, the header list may be followed by a request body.
The header and body requirements vary depending on the request version and the request method, so the appearance of HTTP requests differs widely. For example, in an HTTP 1.0 request, no headers are required. However, in an HTTP 1.1 request, the Host header is required, although it may contain a null value. The Connection header was also added in HTTP 1.1, allowing management of Keep-Alive connections intended to serve multiple requests. While this header was not officially part of the HTTP 1.0 specification, many HTTP 1.0 implementations implicitly support or expect Keep-Alive behavior based on this header. The official HTTP 1.0 specification included the following request methods: GET, HEAD, and POST. The official HTTP 1.1 specification included the following request methods: GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. Extensions to the originally-specified request methods in each version may be supported by some implementations. You can specify any request method supported by your server when constructing the Send String for a BIG-IP GTM HTTP or HTTPS application health monitor.
For example:
 
 
An HTTP version 1.0 GET request that includes two optional headers may appear similar to the following:
GET /index.html HTTP/1.0
Referer: http://www.domain.com/login.cgi
User-Agent: User-agent: Mozilla/3.0Gold
An HTTP version 1.1 POST request that includes the required Host header, several optional headers, a double CR/LF terminating the header list, and a request body containing the POST data may appear similar to the following:
POST /form.cgi HTTP/1.1
Accept: *.*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.0; T312461)
Host: host.domain.com
Connection: Keepalive
Referer: http://www.domain.com/index.html
First=Joe&Last=Cool&userID=123456789
If you require the use of authentication headers, you can enable Basic Authentication on the BIG-IP GTM HTTP and HTTPS application health monitors by configuring the User Name and Password options. Since HTTP version 1.0 or higher is required to support the use of authentication headers, the BIG-IP system uses HTTP version 1.0 by default to send requests when Basic Authentication is enabled.
For detailed specifications for each HTTP version, refer to the following locations:
Note: These links take you to a resource outside of AskF5, and it is possible that the documents may be removed without our knowledge.
 
 
For more information about HTTP 0.9, refer to the original W3C HTTP specification
For more information about HTTP 1.0, refer to RFC1945
For more information about HTTP 1.1, refer to RFC2616
Representation and interpretation of line termination characters
The CR and LF line termination characters are key to the accurate construction and parsing of HTTP requests, regardless of the HTTP version. Depending on the tool used to examine or construct the request, the CR and LF characters may be represented by the following characters:
 
 
Character
Text
 (used to construct GTM monitor Send Strings)
Heximal Representation
 (displayed in tcpdump traces)
Carriage Return (CR)
\r
0x0d
Line
 Feed (LF)
\n
0x0a
 
Recommendations
When formatting a Send String in an HTTP or HTTPS application health monitor, you should consider the following factors regarding the BIG-IP GTM system handling of the CR and LF character sequences specified in the monitor Send String in all versions:
 
 
Each instance of \r is translated to a CR character (0x0d).
Each instance of \n is translated to a LF character (0x0a).
A single CR/LF sequence (0x0d 0x0a) is appended to the end of the Send String.
When Basic Authentication is enabled, the BIG-IP GTM system inserts the Authorization header and a terminating double CR/LF sequence (0x0d 0x0a 0x0d 0x0a) after the last character in the Send String.
Constructing an appropriate HTTP/HTTPS monitor Send String
The following procedures and examples are provided to assist you in constructing an appropriate monitor Send String:
 
 
Without Basic Authentication
With Basic Authentication
Without Basic Authentication
 
 
Type the request line, including the HTTP method, the requested object, including the path and the HTTP version, followed by a single \r\n sequence.
Type any desired headers, following all but the last header with a single \r\n sequence.
If the request contains headers but does not contain a body, terminate the Send String with a single \r\nsequence.
If a request body is specified, precede it with a double \r\n sequence. The double \r\n sequence should separate the last header from the body.
If the request contains a body, no terminating sequence is required.
For example:

   
   
HTTP version 1.1
GET /index.html HTTP/1.1\r\nHost: host.domain.com\r\nConnection: Close\r\n
POST /form.cgi HTTP/1.1\r\nHost: host.domain.com\r\nConnection: Close\r\n\r\nFirst=Jo&Last=Co
HTTP version 1.0
GET /index.html HTTP/1.0\r\n
GET /index.html HTTP/1.0\r\nUser-agent: Mozilla/3.0\r\nReferer: http://my.host.com/log.cgi\r\n
POST /form.cgi HTTP/1.0\r\n\r\nFirst=Joe&Last=Cool
With Basic Authentication
 
 
Type the request line, including the HTTP method, the HTTP version, and the path to the requested object, followed by a single \r\n sequence.
Important: If the request includes headers other than the Authorization header that is inserted by the system, you must specify HTTP version 1.0 or higher in the Send String.
Type any desired headers, following all but the last header with a single \r\n sequence.
No terminating sequence is required, regardless of whether the request contains any headers.
For example:

   
   
HTTP version 1.1
GET /index.html HTTP/1.1\r\nHost: host.domain.com\r\nConnection: Close
POST /form.cgi HTTP/1.1\r\nHost: host.domain.com\r\nConnection: Close\r\n\r\nFirst=Jo&Last=Co
HTTP version 1.0
GET /index.html HTTP/1.0
GET /index.html HTTP/1.0\r\nUser-agent: Mozilla/3.0\r\nReferer: http://my.host.com/log.cgi
POST /form.cgi HTTP/1.0\r\n\r\nFirst=Joe&Last=Cool
------------------------------
The client initiates an HTTP session by opening a TCP connection to the HTTP server with which it wishes to communicate. It then sends request messages to the server, each of which specifies a particular type of action that the user of the HTTP client would like the server to take. Requests can be generated either by specific user action (such as clicking a hyperlink in a Web browser) or indirectly as a result of a prior action (such as a reference to an inline image in an HTML document leading to a request for that image.)
HTTP requests use a message format that is based on the generic message format described in the preceding topic, but specific to the needs of requests. The structure of this format is as follows (see Figure 317):
     
     

      
      <request-line> <general-headers> <request-headers> <entity-headers> <empty-line> [<message-body>] [<message-trailers>]
     
     

     
     

      
      
 
        
Figure 317: HTTP Request Message Format
 
        
This diagram shows the structural elements of an HTTP request and an example of the sorts of headers a request might contain. Like most HTTP requests, this one carries no entity, so there are no entity headers and the message body is empty. See Figure 318 for the HTTP response format.
 
       
 

     
     
Request Line
The generic start line that begins all HTTP messages is called a request line in request messages. Its has a three-fold purpose: to indicate the command or action that the client wants performed; to specify a resource upon which the action should be taken; and to indicate to the server what version of HTTP the client is using. The formal syntax for the request line is:
     
     

      
      <METHOD> <request-uri> <HTTP-VERSION> 
     
     
Method 
The method is simply the type of action that the client wants the server to take; it is always specified in upper case letters. There are eight standard methods defined in HTTP/1.1, of which three are widely used: GET, HEAD and POST. They are called “methods” rather than “commands” because the HTTP standard uses terminology from object-oriented programming. I explain this and also describe the methods themselves in the topic describing HTTP methods.
Request URI 
The request URI is the uniform resource identifier of the resource to which the request applies. While URIs can theoretically refer to either uniform resource locators (URLs) or uniform resource names (URNs), at the present time a URI is almost always an HTTP URL that follows the standard syntax rules of Web URLs. 
Interestingly, the exact form of the URL used in the HTTP request line usually differs from that used in HTML documents or entered by users. This is because some of the information in a full URL is used to control HTTP itself. It is needed as part of the communication between the user and the HTTP client, but not in the request from the client to the server. The standard method of specifying a resource in a request is to include the path and file name in the request line (as well as any optional query information) while specifying the host in the special Host header that must be used in HTTP/1.1 requests. 
For example, suppose the user enters a URL such as this:
     
     

      
      http://www.myfavoritewebsite.com:8080/chatware/chatroom.php
     
     
We obviously don't need to send the “http:” to the server. The client would take the remaining information and split it so the URI was specified as “/chatware/chatroom.php” and the Host line would contain “www.myfavoritewebsite.com:8080”. Thus, the start of the request would look like this:
     
     

      
      GET /chatware/chatroom.php HTTP/1.1 Host: www.myfavoritewebsite.com:8080
     
     
The exception to this rule is when a request is being made to a proxy server. In that case, the request is made using the full URL in its original form, so that it can be processed by the proxy just as the original client did. The request would be:
     
     

      
      GET http://www.myfavoritewebsite.com:8080/chatware/chatroom.php HTTP/1.1
     
     
Finally, there is one special case where a single asterisk can be used instead of a real URL. This is for the OPTIONS method, which does not require the specification of a resource. (Nominally, the asterisk means the method refers to the server itself.)
HTTP Version 
The HTTP-VERSION element tells the server what version the client is using so the server knows how to interpret the request, and what to send and not to send the client in its response. For example, a server receiving a request from a client using versions 0.9 or 1.0 will assume that a transitory connection is being used rather than a persistent one, and will avoid using version 1.1 headers in its reply. The version token is sent in upper case as “HTTP/0.9”, “HTTP/1.0” or “HTTP/1.1”—just the way I've been doing throughout my discussion of the protocol.
Headers
After the request line come any of the headers that the client wants to include in the message; it is in these headers that details are provided to the server about the request. The headers all use the same structure, but are organized into categories based on the functions they serve, and whether they are specific to one kind of message or not:
     
     
General Headers: General headers refer mainly to the message itself, as opposed to its contents, and are used to control its processing or provide the recipient with extra information. They are not particular to either request or response messages, so they can appear in either. They are likewise not specifically relevant to any entity the message may be carrying. 
Request Headers: These headers convey to the server more details about the nature of the client's request, and give the client more control over how the request is handled. For example, special request headers can be used by the client to specify a conditional request—one that is only filled if certain criteria are met. Others can tell the server which formats or encodings the client is able to process in a response message. 
Entity Headers: These are headers that describe the entity contained in the body of the request, if any.
Request headers are obviously used only in request messages, but both general headers and entity headers can appear in either a request or a response message. Since there are so many headers and most are not particular to one message type, they are described in detail in their own complete section.
Key Concept: HTTP requests are the means by which HTTP clients ask servers to take a particular type of action, such as sending a file or processing user input. Each request message begins with a request line, which contains three critical pieces of information: the method (type of action) the client is requesting; the URI of the resource upon which the client wishes the action to be performed, and the version of HTTP that the client is using. After the request line come a set of message headers related to the request, followed by a blank line and then optionally, the message body of the request.