一般來說，Web伺服器預設的只支援Post和Get這兩種“只讀”的請求方法。但是隨著Ajax XMLHttpRequest 和 REST風格應用的深入，我們發現Http 1.1協議還支援如下請求方法（Request Method）：

• OPTIONS

• HEAD

• DELETE

• PUT

• TRACE

• CONNECT

Get是最常用的，就是向Web Server發請求“獲取”資源；那麼Post就是向Web Server“郵寄”一些封裝的資料包獲取資源，這兩者方法嚴格的說都是“索取”行為。

顧名思義，Delete方法就是通過http請求刪除指定的URL上的資源啦，Delete請求一般會返回3種狀態碼：

• 200 (OK) - 刪除成功，同時返回已經刪除的資源
• 202 (Accepted) - 刪除請求已經接受，但沒有被立即執行（資源也許已經被轉移到了待刪除區域）
• 204 (No Content) - 刪除請求已經被執行，但是沒有返回資源（也許是請求刪除不存在的資源造成的）

Put方法就不多廢話了，就是往Web Server上直接扔資源（上傳資源）嘛，不過實際操作起來可能會讓諸位看官喝一壺，E文定義如下：

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.

上面說的都是虛的，實戰才是硬道理！

• 首先，我們要讓Web Server支援Delete 和 Put請求方法，以大家熟悉的Tomcat為例：

在Tomcat的web.xml 檔案中配置 org.apache.catalina.servlets.DefaultServlet 的初始化引數

<init-param> <param-name>readonly</param-name> <param-value>false</param-value> </init-param>

readonly引數預設是true，即不允許delete和put操作，所以預設的通過XMLHttpRequest物件的put或者delete方法訪問就會報告 http 403 forbidden 錯誤。

• 接下來，從客戶端通過 Ajax XMLHTTPRequest 發起 DELETE/PUT 請求：

  function getXMLHTTPRequest(){ if (XMLHttpRequest) { return new XMLHttpRequest(); } else { try{ return new ActiveXObject('Msxml2.XMLHTTP'); }catch(e){ return new ActiveXObject('Microsoft.XMLHTTP'); } } } var req = getXMLHTTPRequest(); req.open('DELETE','http://localhost/test.jsp',false); req.send(null); document.write(req.responseText);

• WebDAV也需要使用到這2種Http請求方法。