HTTP1.1 Notes 6, Method Definitions

[b]Safe and Idempotent Methods[/b]

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

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
A sequence that never has side effects is idempotent

[b]OPTIONS[/b]
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

[b]GET[/b]
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI
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
The semantics of the GET method change to a "partial GET" if the request message includes a Range header field

[b]HEAD[/b]
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response

[b]POST[/b]
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
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

[b]PUT[/b]
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
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI
A single resource MAY be identified by many different URIs

[b]DELETE[/b]
The DELETE method requests that the origin server delete the resource identified by the Request-URI

[b]TRACE[/b]
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
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

[b]CONNECT[/b]
This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel

一般而言Web Server只支持GET和POST，有的可以通过修改默认配置来支持PUT和DELETE，而有的没有实现TRACE