Shulou(Shulou.com)06/02 Report--

GET: the get method is used to get the specified form of the request page

POST: the post method is similar to the get method, but the biggest difference is that the GET method has no request content, while POST has the request content, and the data sent by the GET request will be displayed on the browser side.

The HEAD:HEAD method is the same as the get method except that the server cannot respond to the message body.

The PUT:PUT method is used to request the server to store the request content under the request resource, and if the request resource already exists in the server, the original data will be replaced with the data in the request.

The DELETE:DELETE method is used to request the resource server to delete the specified resource.

The TRACE: TRACE method is generally used to fire a message loop at the remote application layer. The echo server receives the request

CONNECT: for agents that can dynamically cut to the tunnel

The OPTIONS:OPTIONS method is used to request the resource identified by the URL and the functional options that can be used during request / response communication.

HTTP goes deep into the http request.

HTTP (HyperText Transfer Protocol) is a set of rules for computers to communicate over a network. Computer experts have designed HTTP to enable HTTP clients (such as Web browsers) to request information and services from HTTP servers (Web servers). The current version of the HTTP protocol is that 1.1.HTTP is a stateless protocol, which means that there is no need to establish a persistent connection between the Web browser and the Web server, which means that when a client makes a request to the server, and then the Web server returns a response (response) The connection is closed and no information about the connection is retained on the server side. Http follows the request (Request) / reply (Response) model. The Web browser sends a request to the Web server, and the Web server processes the request and returns the appropriate reply. All HTTP connections are constructed into a set of requests and replies.

HTTP uses content types, which means that all files returned by the Web server to the Web browser have related types. All of these types are modeled on the MIME Internet mail protocol, where the Web server tells Web browsers what kind the file has, whether it is an HTML document, an GIF format image, a sound file, or a stand-alone application. Most Web browsers have a series of configurable helper applications that tell browsers how to handle various types of content sent from Web servers.

The HTTP communication mechanism is that during a complete HTTP communication, the following seven steps will be completed between the Web browser and the Web server:

(1) establish a TCP connection

Before the start of HTTP work, Web browsers first establish a connection with the Web server through the network, which is completed through TCP. This protocol and IP protocol work together to build Internet, that is, the famous TCP/IP protocol family, so Internet is also called TCP/IP network. HTTP is a higher-level application layer protocol than TCP. According to the rules, only after the low-level protocol has been established can the connection of the higher-layer protocol be made. Therefore, the TCP connection must be established first. The port number of the general TCP connection is 80.

(2) Web browser sends request commands to Web server

Once a TCP connection is established, the Web browser sends a request command to the Web server

For example: GET/sample/hello.jsp HTTP/1.1

(3) Web browser sends request header information

After the browser sends its request command, it also sends some other information to the Web server in the form of a header message, and then the browser sends a blank line to inform the server that it has finished sending the header message.

(4) Web server reply

After the client makes a request to the server, the server will send back the reply from the client

HTTP/1.1 200 OK

The first part of the reply is the version number and reply status code of the protocol.

(5) Web server sends response header information

Just as the client sends information about itself with the request, the server sends its own data and the requested document to the user with the reply.

(6) the Web server sends data to the browser

After the Web server sends the header information to the browser, it sends a blank line to indicate that the header information is sent to this end, and then it sends the actual data requested by the user in the format described in the Content-Type response header message.

(7) Web server closes TCP connection

In general, once the Web server sends the request data to the browser, it closes the TCP connection, and then if the browser or server adds this line of code to its header information

Connection:keep-alive

The TCP connection will remain open after it is sent, so the browser can continue to send requests over the same connection. Staying connected saves the time it takes to establish a new connection for each request and saves network bandwidth.

HTTP request format

When the browser makes a request to the Web server, it passes a data block, that is, the request information, to the server. The HTTP request information consists of three parts:

L request method URI protocol / version

L request header (Request Header)

L request body

Here is an example of an HTTP request:

GET/sample.jspHTTP/1.1

Accept:image/gif.image/jpeg,*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0 (compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

Username=jinqiao&password=1234

(1) request method URI protocol / version

The first line of the request is "method URL discussion / version": GET/sample.jsp HTTP/1.1

In the above code, "GET" represents the request method, "/ sample.jsp" represents URI, and "HTTP/1.1 represents the protocol and the version of the protocol.

According to the HTTP standard, HTTP requests can use a variety of request methods. For example, HTTP1.1 supports seven request methods: GET, POST, HEAD, OPTIONS, PUT, DELETE and TARCE. In Internet applications, the most commonly used methods are GET and POST.

URL fully specifies the network resources to be accessed, usually by giving a relative directory relative to the root directory of the server, so it always starts with "/". Finally, the protocol version declares the version of HTTP used in the communication process.

(2) request header (Request Header)

The request header contains a lot of useful information about the client environment and the request body. For example, the request header can declare the language used by the browser, the length of the request body, and so on.

Accept:image/gif.image/jpeg.*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0 (compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate.

(3) request text

There is a blank line between the request header and the request body, which is very important, indicating that the request header has ended, followed by the request body. The request body can contain the query string information submitted by the customer:

Username=jinqiao&password=1234

In the HTTP request in the above example, the body of the request has only one line. Of course, in practical applications, the HTTP request body can contain more content.

HTTP request method I only discuss GET method and POST method here

L GET method

The GET method is the default HTTP request method. We usually use the GET method to submit the form data, but the form data submitted by the GET method is only simply encoded, and it will be sent to the Web server as part of the URL. Therefore, there is a security risk if we use the GET method to submit the form data. For example

Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB

From the above URL request, it is easy to recognize the content of the form submission. (? In addition, because the data submitted by the GET method is part of the URL request, the amount of data submitted cannot be too large.

L POST method

The POST method is an alternative to the GET method, which mainly submits form data, especially large quantities of data, to the Web server. The POST method overcomes some shortcomings of the GET method. When the form data is submitted through the POST method, the data is transmitted to the Web server not as part of the URL request but as standard data, which overcomes the shortcomings that the information in the GET method can not be kept secret and the amount of data is too small. Therefore, for the sake of security and respect for user privacy, the POST method is usually used when the form is submitted.

From a programming perspective, if the user submits data through the GET method, the data is stored in the QUERY_STRING environment variable, while the data submitted by the POST method can be obtained from the standard input stream.

The HTTP response is similar to the HTTP request, and the HTTP response consists of three parts, namely:

L protocol status version code description

L response header (Response Header)

L response text

Here is an example of an HTTP response:

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:23:42 GMT

Content-Length:112

Sample HTTP response

Hello HTTP!

The protocol status code describes the first line of the HTTP response similar to the first line of the HTTP request, indicating that the protocol used for communication is that the HTTP1.1 server has successfully processed the request made by the client.

HTTP/1.1 200 OK

The response header (Response Header) contains as much useful information as the request header, such as server type, date and time, content type, and length:

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:13:33 GMT

Content-Type:text/html

Last-Moified:Mon,6 Oct 2003 13:23:42 GMT

Content-Length:112

The response body is the HTML page returned by the server:

Sample HTTP response

Hello HTTP!

The response header and the text must also be separated by blank lines.

L HTTP response code

The HTTP response code, also known as the status code, reflects the status of the HTTP request processed by the Web server. The HTTP response code consists of three digits, the first digit of which defines the type of response code:

1XX-Information class (Information), indicating that a request has been received from a Web browser and is in the process of further processing

2XX-success class (Successful), indicating that the user request was received, understood and processed correctly, for example: 200OK

3XX-redirect class (Redirection), indicating that the request was not successful and the customer must take further action.

4XX-client error (Client Error), indicating that there is an error in the request submitted by the client for example: 404NOT

Found, which means that the document referenced in the request does not exist.

5XX-Server error (Server Error) indicates that the server was unable to complete the processing of the request: for example, 500

For us Web developers, mastering the HTTP response code helps to improve the efficiency and accuracy of Web application debugging.

Secure connection

One of the most common uses of Web applications is e-commerce, which can use Web server-side programs to enable people to shop online. It is important to point out that by default, it is not safe to send information through Internet. If someone happens to intercept a message you send to a friend, he can open it and imagine that there is your credit card number in it. Fortunately, how bad it would be. Many Web servers and Web browsers have the ability to create secure connections so that they can communicate securely.

The most common standard for providing secure connections through Internet is the secure Sockets layer (Secure Sockets layer,SSl) protocol. The SSL protocol is an application layer protocol (like HTTP) for the secure exchange of data over Web, and SSL uses a public key encoding system. In essence, this means that each party in the business has a public and private key. When one party uses the other party's public key to encode, only the person who has the matching key can decode it. To put it simply, public key coding provides a secure method for exchanging data between two parties. After a SSL connection is established, both the client and the server exchange public keys and verify them before making business contacts. Once the keys of both parties have been verified, the data can be safely exchanged.

GET

Get resources by requesting URI

POST

Used to add new content

PUT

Used to modify something

DELETE

Delete something

CONNECT

Used for proxy transmission, such as using SSL

OPTIONS

Ask which methods can be executed

PATCH

Partial document changes

PROPFIND, (wedav)

View Properti

PROPPATCH, (wedav)

Set properti

MKCOL, (wedav)

Create a collection (folder)

COPY, (wedav)

Copy

MOVE, (wedav)

move

LOCK, (wedav)

Add lock

UNLOCK (wedav)

Unlock

TRACE

For remote diagnostic server

HEAD

Similar to GET, but does not return body information, which is used to check whether the object exists and to get the metadata of the object

In apache2, the access control methods that can use Limit,LimitExcept include: GET, POST, PUT, DELETE, CONNECT,OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.

Where HEAD GET POST OPTIONS PROPFIND is the method related to reading, and MKCOL PUT DELETE LOCK UNLOCK COPY MOVE PROPPATCH is the method related to modification.

Part of Hypertext Transfer Protocol-HTTP/1.1

RFC 2616 Fielding, et al.

9 Method Definitions

The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.

The Host request-header field (section 14.23) MUST accompany all HTTP/1.1 requests.

9.1 Safe and Idempotent Methods

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.

A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).

9.2 OPTIONS

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method are not cacheable.

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a

Body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

9.3 GET

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field (s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.

See section 15.1.3 for security considerations when used for forms.

9.4 HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

9.5 POST

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

-Annotation of existing resources;- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;- Providing a block of data, such as the result of submitting a form, to a data-handling process;- Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

POST requests MUST obey the message transmission requirements set out in section 8.2.

See section 15.1.3 for security considerations.

9.6 PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request-- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI

It MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements set out in section 8.2.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

9.7 DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

9.8 TRACE

The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the

Origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.

9.9 CONNECT

This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

Later reproduced from: http://www.cnblogs.com/yin-jingyu/archive/2011/08/01/2123548.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.