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

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

按慣例，在標識應用時，以其重要性順序排列。

Product    = token ["/" product-version]

product-version   = token

例如：

  User-Agent: CERN-LineMode/2.15 libwww/2.17b3

  Server: /0.8.4

  產品標識應當短小，因而禁止利用該域填寫廣告或其它無關資訊。雖然任何符號字元都可能出現在產品版本中，該符號應當只用於做版本定義，也就是說，同一個產品的連續版本之間只能透過產品版本值進行區分。

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

4.  HTTP 訊息（HTTP Message）

 

4.1  訊息型別（Message Types）

 

  HTTP訊息由客戶端到的請求和由伺服器到客戶端的回應組成。

 

HTTP-message  = Simple-Request    ; HTTP/0.9 messages

  | Simple-Response

  | Full-Request    ; HTTP/1.0 messages

   | Full-Response

 

  完整的請求（Full-Request）和完整的回應（Full-Response）都使用822[7]中實體傳輸部分規定的訊息格式。兩者的訊息都可能包括標題域（headers，可選）、實體主體（entity body）。實體主體與標題間透過空行來分隔（即CRLF前沒有內容的行）。

 

Full-Request    = Request-Line    ; Section 5.1

  *( General-Header  ; Section 4.3

  | Request-Header  ; Section 5.2

  | Entity-Header )  ; Section 7.1

  CRLF

  [ Entity-Body ]  ; Section 7.2

 

Full-Response    = Status-Line    ; Section 6.1

  *( General-Header  ; Section 4.3

  | Response-Header  ; Section 6.2

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 21]

 

| Entity-Header ) ; Section 7.1

   CRLF

  [ Entity-Body ]  ; Section 7.2

 

  簡單請求（Simple_Request）與簡單回應（Simple-Response）不允許使用任何標題資訊，並限制只能使用唯一的請求方法（GET）

 

  Simple-Request  = "GET" SP Request-URI CRLF

 

  Simple-Response = [ Entity-Body ]

  不提倡使用簡單方式請求格式，因為它防止了伺服器在接到簡單請求時對返回實體的介質型別進行驗證。

 

 

4.2  訊息標題（Message Headers）

  HTTP標題域，包括主標題（General-Header,4.3節）、請求標題（Request-Header ,5.2節）、回應標題（Response-Header ,6.2節）及實體標題（Entity-Header,7.1節），都遵照RFC822-3.1節[7]給出的通用格式定義。每個標題域由後緊跟冒號的名字，單空格（SP），字元及域值組成。域名是大小寫敏感的。雖然不提倡，標題域還是可以擴充套件成多行使用，只要這些行以一個以上的SP或HT開頭就行。

 

HTTP-header    = field-name ":" [ field-value ] CRLF

 

field-name  = token

field-value  = *( field-content | LWS )

 

field-content    =

  and consisting of either *TEXT or combinations

  of token, tspecials, and quoted-string>

標題域接收的順序並不重要，但良好的習慣是，先傳送主標題，然後是請求標題或回應標題，最後是實體標題。

  當且僅當標題域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名的HTTP標題域才可以表示在一個訊息裡。而且必須能在不改變訊息語法的前提下，將併發的域值加到第一個值後面，之間用逗號分隔，最終能將多個標題域結合成“域名：域值”對。

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 22]

 

4.3  普通標題域（General Header Fields）

 

  有幾種標題域是請求與回應都要使用的，但並不用於被傳輸的實體。這些標題只用於被傳輸的訊息。

 

General-Header = Date    ; Section 10.6

  | Pragma  ; Section 10.12

  普通標題域名稱只有在與版本的變化結合起來後，才能進行可靠的擴充套件。實際上，新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被視為實體域。

 

5. 請求（Request）

  從客戶端到伺服器端的請求訊息包括，訊息首行中，對資源的請求方法、資源的識別符號及使用的協議。考慮到侷限性更大的HTTP/0.9的向後相容問題，有兩種合法的HTTP請求格式：

 

Request    = Simple-Request | Full-Request

 

Simple-Request  = "GET" SP Request-URI CRLF

 

Full-Request    = Request-Line  ; Section 5.1

*( General-Header ; Section 4.3

| Request-Header ; Section 5.2

| Entity-Header ) ; Section 7.1

CRLF

[ Entity-Body ] ; Section 7.2

 

  如果HTTP/1.0伺服器收到簡單請求，它必須回應一個HTTP/0.9格式的簡單回應。HTTP/1.0的客戶端有能力接收完整回應，但不能產生簡單請求。

 

5.1  請求佇列（Request-Line）

 

  請求佇列以一個方法符號開頭，跟在請求URI及協議版本的後面，以CRLF為結尾。該元素用空格SP分隔。除了最後的CRLF，不允許出現單獨的CR或LF符。

 

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 23]

 

  注意，簡單請求與完整請求的請求佇列之間的區別在於是否有HTTP版本域和是否可以使用除GET以外的其它方法。

 

 

5.1.1 方法（Method）

 

  方法代號指明瞭將要以何種方式來訪問由請求URI指定的資源。方法是大小寫敏感的。

 

Method  = "GET"　     ; Section 8.1

|"HEAD" ; Section 8.2

| "POST" ; Section 8.3

| extension-method

 

  extension-method = token

 

  可以訪問指定資源的方法列表是可以動態變化的；如果用某種方法訪問資源被拒絕，客戶端可從回應中的返回碼得到通知。伺服器端在方法無法識別或沒有實現時，返回狀態程式碼501（尚未沒實現）。

 

  這些方法被HTTP/1.0的應用程式普遍使用，完整定義請參見第8節。

 

5.1.2 請求URI（Request-URI）

 

  請求URI就是統一資源識別符號（3.2節），用來標識要請求的資源。

 

Request-URI    = absoluteURI | abs_path

 

  上面兩種請求URI方式可根據實際的請求方式選擇使用。

  絕對URI（absoluteURI）格式只在（）在產生請求時使用。代理的責任是將請求向前推送，並將回應返回。如果請求是GET或HEAD方式，而且之前的回應被快取，如果代理忽略標題域的過期資訊限制，它可能使用快取中的訊息。注意，代理可能將請求推送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的伺服器。為了避免請求迴圈，代理必須能夠識別它的所有伺服器名，包括別名、本地變數及數字形式的。下面是一個請求佇列的例子：

 

GET HTTP/1.0

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 24]

 

  最普通的請求URI形式就是原始伺服器或閘道器用來標識資源的方式。在這種方式下，只有給出絕對路徑的URI才能被傳輸（見3.2.1節）。例如，如客戶端希望直接從原始伺服器上接收資源，它們將產生一個與主機””80埠的TCP連線，並在完整請求之後傳送下面的命令：

 

GET /pub/WWW/TheProject.html HTTP/1.0

 

  注意絕對路徑不可以為空，如果URI中沒有內容，也必須加上一個”/”（server ）。

 

  請求URI以編碼字串方式傳輸，有些字元可能在傳輸過程中被轉義（escape），如變成“%HEXHEX”形式。具體這方面內容請參見RFC1738[4]。原始伺服器在正確解釋請求之前必須對請求URI進行解碼。

 

5.2  請求標題域（Request Header Fields）

 

  請求標題域允許客戶端向伺服器端傳遞該請求的附加資訊及客戶端資訊。該域做為請求的修飾部分，遵照語言程式引數的語法形式。

 

Request-Header = Authorization    ; Section 10.2

  | From    ; Section 10.8

  | If-Modified-Since  ; Section 10.9

  | Referer    ; Section 10.13

  | User-Agent  ; Section 10.15

 

  請求標題域名只有在與協議版本的變化結合起來後，才能進行可靠的擴充套件。實際上，新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被視為實體域。

 

6.  回應（Response）

 

  在接收、解釋請求訊息後，伺服器端返回HTTP回應訊息。

 

Response    = Simple-Response | Full-Response

 

Simple-Response   = [ Entity-Body ]

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 25]

 

Full-Response = Status-Line    ; Section 6.1

  *( General-Header  ; Section 4.3

  | Response-Header  ; Section 6.2

  | Entity-Header )  ; Section 7.1

  CRLF

  [ Entity-Body ]  ; Section 7.2

 

  當請求是HTTP/0.9的或者伺服器端只支援HTTP/0.9時，只能以Simple-Response方式回應。如果客戶端傳送HTTP/1.0完整請求後，接收到的回應不是以狀態行（Status-Line）開頭的，客戶端將其視為簡單回應，並相應對其進行分析。注意，簡單請求只包括實體主體，它在伺服器端關閉連線時終止。

 

6.1  狀態行（Status-Line）

 

  完整回應訊息的第一行就是狀態行，它依次由協議版本、數字形式的狀態程式碼、及相應的詞語文字組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的CR或LF符。

 

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

 

  狀態行總是以協議版本及狀態程式碼開頭，如：

 

"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

  （如，”HTTP/1.0 200”）。

 

這種表示方式並不足以區分完整請求和簡單請求。簡單回應可能允許這種出現在實體主體的開始部分，但會引起訊息的誤解。因為大多數HTTP/0.9的伺服器都只能回應”text/html”型別，在這種情況下，不可能產生完整的回應。

 

 

6.1.1 狀態程式碼和原因分析（Status Code and Reason Phrase）

 

  狀態程式碼（Status-Code）由3位數字組成，表示請求是否被理解或被滿足。原因分析是用簡短的文字來描述狀態程式碼產生的原因。狀態程式碼用來支援自動操作，原因分析是為人類準備的。客戶端不需要檢查或顯示原因分析。

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational   [Page 26]

 

  狀態程式碼的第一位數字定義了回應的類別，後面兩位數字沒有具體分類。首位數字有5種取值可能：

 

o 1xx:：保留，將來使用。

 

o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。

 

o 3xx：重定向（Redirection）－ 要完成請求必須進行進一步操作。

 

o 4xx：客戶端出錯 － 請求有語法錯誤或無法實現。

 

o 5xx：伺服器端出錯 － 伺服器無法實現合法的請求。

 

  HTTP/1.0的狀態程式碼、原因解釋在下面給出。下面的原因解釋只是建議採用，可任意更改，而不會對協議造成影響。完整的程式碼定義在第9節。

  Status-Code  = "200"  ; OK

  | "201"  ; Created

  | "202"  ; Accepted

  | "204"  ; No Content

  | "301"  ; Moved Permanently