rfc1945-http1.0自譯本-(6) (轉)

rfc1945-http1.0自譯本-(6) (轉)[@more@] 

8.1  GET

 

  GET方法就是以實體方式得到由請求URI所指定資源的資訊。如果請求URI只是一個資料產生過程，那麼最終要在回應實體中返回的是由該處理過程的結果所指向的資源，而不是返回該處理過程的描述文字，除非那段文字恰好是處理的輸出。

  如果請求訊息包含If-Modified-Since標題域，GET方法的語法就變成“條件GET”，即“（conditional GET）”。 條件GET方法可以對指定資源進行判斷，如果它在If-Modified-Since標題域（見10.9節）中的指定日期後發生了，才啟動傳輸，否則不傳輸。這種條件GET

允許被快取的實體在不必經過多次請求或不必要的資料傳輸就能進行重新整理，從而有助於降低負載。

 :namespace prefix = o ns = "urn:schemas--com::office" />

8.2  HEAD

 

  HEAD方法與GET幾乎一樣，區別在於，HEAD方法不讓在回應中返回任何實體。對HEAD請求的回應部分來說，它的HTTP標題中包含的元資訊與透過GET請求所得到的是相同的。透過使用這種方法，不必傳輸整個實體主體，就可以得到請求URI所指定資源的元資訊。該方法通常用來測試超連結的合法性、可訪問性及最近更新。

  與條件GET不同，不存在所謂的“條件HEAD”，即"conditional HEAD"。即使在HEAD請求中指定If-Modified-Since標題域，它也會被忽略。

 

8.3  POST

 

  POST方法用來向目的伺服器發出請求，要求它接受被附在請求後的實體，並把它當作請求佇列（Request-Line）中請求URI所指定資源的附加新子項。POST被設計成用統一的方法實現下列功能：

 

o 對現有資源的註釋（Annotation of existing res）；

 

o 向電子公告欄、新聞組，列表或類似討論組傳送訊息；

 

o 提交資料塊，如將表格（fo[3]）的結果提交給資料處理過程；

 

o 透過附加操作來擴充套件。

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 31]

 

  POST方法的實際功能由伺服器來決定，而且通常依賴於請求URI。在POST過程中，實體是URI的從屬部分，就好象從屬於包含它的目錄、新聞組檔案從屬於發出該檔案的新聞組、記錄從屬於其所在的資料庫一樣。

  成功的POST不需要在原始伺服器建立實體，並將其做為資源；也不需要為未來的訪問提供條件。也就是說，POST方法不一定會指向URI指定的資源。在這種情況下，200（成功）或204（無內容）都是適當的回應狀態，取決於實際回應實體中對結果的描述。

  如果在原始伺服器上建立了資源，回應應是201（已建立），幷包含一個實體（對”text/html”型別最為適合），該實體中記錄著對新資源請求的狀態描述。

  在所有的HTTP/1.0的POST請求中，必須指定合法的內容長度（Content-Length）。如果HTTP/1.0伺服器在接收到請求訊息內容時無法確定其長度，就會返回400（請求）程式碼。

  應用不能快取對POST請求的回應，因為做為應用程式來說，它們沒有辦法知道伺服器在未來的請求中將如何回應。

 

9.  狀態程式碼定義（Status Code Definitions）

 

  每個狀態程式碼都將在下面描述，包括它們將對應哪個方法、以及回應中需要的全部元資訊。

 

9.1  訊息1xx（Informational 1xx）

 

  該類狀態程式碼用於表示臨時回應。臨時回應由狀態行（Status-Line）及可選標題組成，由空行終止。HTTP/1.0中沒有定義任何1xx的狀態程式碼，所以它們不是對HTTP/1.0請求的合法回應。實際上，它們主要用於實驗用途，這已經超出本文件的範圍。

 

9.2  成功2xx（Succesul 2xx）

 

  表示客戶端請求被成功接收、理解、接受。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 32]

 

200 OK

  請求成功。回應的資訊依賴於請求所使用的方法，如下：

 

GET    要請求的資源已經放在回應的實體中了。

 

HEAD    沒有實體主體，回應中只包括標題資訊。?

 

POST    實體（描述或包含操作的結果）。

 

201 Created

 

請求完成，結果是建立了新資源。新建立資源的URI可在回應的實體中得到。原始伺服器應在發出該狀態程式碼前建立該資源。如果該操作不能立即完成，伺服器必須在該資源可用時在回應主體中給出提示，否則，伺服器端應回應202（可被接受）。

 

在本文定義的方法，只有POST可以建立資源。

 

202 Accepted

 

請求被接受，但處理尚未完成。請求可能不一定會最終完成，有可能被處理過程隨時中斷，在這種情況下，沒有辦法在非同步操作中重新傳送狀態程式碼。

 

202回應是沒有義務的，這樣做的目的是允許伺服器不必等到和伺服器間的連線結束，就可以響應其它過程的請求（象每天執行一次的，基於批處理的過程）。

 

在某些回應中返回的實體中包括當前請求的狀態指示、狀態監視器指標或使用者對請求能否實現的評估資訊。

 

204 No Content

 

伺服器端已經實現了請求，但是沒有返回新的資訊。如果客戶是使用者代理，則勿需為此更新自身的文件檢視。該回應主要是為了在不影響使用者代理啟用文件檢視的前提下，進行script語句的輸入及其它操作。該回應還可能包括新的、以實體標題形式表示的元資訊，它可被當前使用者代理啟用檢視中的文件所使用。

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 33]

 

9.3  重定向（Redirection 3xx）

 

該類狀態碼錶示使用者代理要想完成請求，還需要發出進一步的操作。這些操作只有當後跟的請求是GET或HEAD時，才可由使用者代理來實現，而不用與使用者進行互動。使用者代理永遠也不要對請求進行5次以上的重定向操作，這樣可能導致無限迴圈。

 

300 Multiple Choices

 

該狀態碼不被HTTP/1.0的應用程式直接使用，只是做為3xx型別回應的預設解釋。

 

存在多個可用的被請求資源。

 

除非是HEAD請求，否則回應的實體中必須包括這些資源的字元列表及位置資訊，由使用者或使用者代理來決定哪個是最適合的。

 

如果伺服器有首選，它應將對應的URL資訊存放在位置域（Location field）處，使用者代理會根據此域的值來實現自動的重定向。

 

301 Moved Permanently

 

請求到的資源都會分配一個永久的URL，這樣就可以在將來透過該URL來訪問此資源。有編輯連結功能的客戶端會盡可能地根據伺服器端傳回的新連結而自動更新請求URI。

 

新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體（Entity-Body）必須包括對新URL超連結的簡要描述。

 

如果用POST方法發出請求，而接收到301回應狀態碼。在這種情況下，除非使用者確認，否則使用者代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 34]

 

注意：當在接收到301狀態碼後而自動重定向POST請求時，一些現存的使用者代理會錯誤地將其改為GET請求。

 

302 Moved Temporarily

 

請求到的資源在一個不同的URL處臨時儲存。因為重定向有時會被更改，客戶端應繼續用請求URI來發出以後的請求。

 

新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體（Entity-Body）必須包括對新URL超連結的簡要描述。

 

如果用POST方法發出請求，而接收到302回應狀態碼。在這種情況下，除非使用者確認，否則使用者代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

 

注意：當在接收到302狀態碼後而自動重定向POST請求時，一些現存的使用者代理會錯誤地將其改為GET請求。

 

304 Not Modified

 

如果客戶端成功了條件GET請求，而對應檔案自If-Modified-Since域所指定的日期以來就沒有更新過，伺服器應當回應此狀態碼，而不是將實體主體傳送給客戶端。回應標題域中只應包括一些相關資訊，比如快取管理器、與實體最近更新（entity's Last-Modified）日期無關的修改。相關標題域的例子有：日期、伺服器、過期時間。每當304回應中給出的域值發生變化，快取都應當對快取的實體進行更新。

 

9.4  客戶端錯誤（Client Error ）4xx

 

  4xx類的狀態碼錶示客戶端發生錯誤。如果客戶端在收到4xx程式碼時請求還沒有完成，它應當立即終止向伺服器傳送資料。除了回應HEAD請求外，不論錯誤是臨時的還是永久的，伺服器端都必須在回應的實體中包含錯誤狀態的解釋。這些狀態碼適用於任何請求方法。

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 35]

 

  注意：如果客戶端正在傳送資料，伺服器端的TCP實現應當小心，以確保客戶端在關閉輸入連線之前收到回應包。如果客戶端在關閉後仍舊向伺服器傳送資料，伺服器會給客戶端傳送一個復位包，清空客戶端尚未處理的輸入緩衝區，以終止HTTP應用程式的讀取、解釋活動。

 

400 非法請求（Bad Request）

 

如果請求的語法不對，伺服器將無法理解。客戶端在對該請求做出更改之前，不應再次向伺服器重複傳送該請求。

 

401 未授權（Unauthorized）

 

請求需要使用者授權。回應中的WWW-Authenticate標題域（10.16節）應提示使用者以授權方式請求資源。客戶端應使用合適的授權標題域（10.2節）來重複該請求。如果請求中已經包括了授權信任資訊，那回應的401表示此授權被拒絕。如果使用者代理在多次嘗試之後，回應一樣還是返回401狀態程式碼，使用者應當察看一下回應的實體，因為在實體中會包括一些相關的動態資訊。HTTP訪問授權會在11節中解釋。

 

403 禁止（Forbidden）

 

伺服器理解請求，但是拒絕實現該請求。授權對此沒有幫助，客戶端應當停止重複傳送此請求。如果不是用HEAD請求方法，而且伺服器端願意公佈請求未被實現原因的前提下，伺服器會將拒絕原因寫在回應實體中。該狀態碼一般用於伺服器端不想公佈請求被拒絕的細節或沒有其它的回應可用。

 

404 沒有找到（Not Found）

 

伺服器沒有找到與請求URI相符的資源。404狀態碼並不指明狀況是臨時性的還是永久性的。如果伺服器不希望為客戶端提供這方面的資訊，還回應403（禁止）狀態碼。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 36]

 

9.5  伺服器錯誤（Server Error ）5xx

 

回應程式碼以‘5’開頭的狀態碼錶示伺服器端發現自己出現錯誤，不能繼續執行請求。如果客戶端在收到5xx狀態碼時，請求尚未完成，它應當立即停止向伺服器傳送資料。除了回應HEAD請求外，伺服器應當在其回應實體中包括對錯誤情況的解釋、並指明是臨時性的還永久性的。

 

這類回應程式碼沒有標題域，可適用於任何請求方法。

 

500 伺服器內部錯誤（Internal Server Error）

 

伺服器碰到了意外情況，使其無法繼續回應請求。

 

501 未實現（Not Implemented）

 

伺服器無法提供對請求中所要求功能的支援。如果伺服器無法識別請求方法就會回應此狀態程式碼，這意味著不能回應請求所要求的任何資源。

 

502 非法閘道器（Bad Gateway）

 

  充當閘道器或代理的伺服器從要傳送請求的上游（upstream）伺服器收到非法的回應。

 

503 服務不可用（Service Unavailable）

 

伺服器當前無法處理請求。這一般是由於伺服器臨時性超載或維護引起的。該狀態碼暗示情況是暫時性的，要產生一些延遲。

注意：503狀態碼並沒有暗示伺服器在超載時一定要返回此狀態碼。一些伺服器可能希望在超載時採用簡單處理，即斷掉連線。

 

10.  標題域定義（Header Field Definitions）

 

本節定義了HTTP/1.0標題域常用的語法及語義。無論是傳送方還是接收方，都有可能做為客戶端或伺服器端，具體角色取決於在此時刻究竟是誰在接收、誰在傳送。

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 37]

 

10.1  允許（Allow）

 

  表示由請求URI所指定的資源支援在Allow實體標題域中列出的方法，目的是讓接收方更清楚地知道請求此資源的合法方式。Allow標題域不允許在POST方法中使用，如果非要這麼做，將被忽略。

 

Allow  = "Allow" ":" 1#method

 

Example of use:

 

  Allow: GET, HEAD

 

該域不能防止客戶端嘗試其它方法。但實際上由Allow標題域中的值所表示的指示資訊是有用的，應當被遵守。實際的Allow方法集在每次向原始伺服器上發出請求時定義。

由於使用者代理（user agent）可能出於其它目的與原始伺服器通訊，做為代理（）來說，即使無法識別請求所指定的所有方法，也不能修改該請求的Allow標題域。

Allow標題域並不表示伺服器實現了哪些方法。

 

10.2  授權（Authorization）

 

  通常，使用者代理在收到401（未授權）回應時，可能（也可能不會）希望伺服器對其授權。如果希望授權，使用者代理將在請求中加入授權請求標題（Authorization request-header