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

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

要解釋的名詞＝名詞解釋（name = definition）

規則的名字（name）就是它本身（不帶任何尖括號，“”），後面跟個等號＝，然後就是該規則的定義。如果規則需要用多個行來描述，利用空格進行縮排格式排版。某些基本的規則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號來幫助理解規則名的使用。

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

字面意思（"literal"）

  文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。

 

規則1｜規則2（rule1 | rule2）

  “｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。

 

（規則1　規則2）（(rule1 rule2)）

在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩種意思，即“元素1　元素2　元素4”和“元素1　元素3　元素4”

 

*規則（*rule）

在元素前加星號“*”表示迴圈，其完整形式是“*元素”，表明元素最少產生次，最多次。預設值是0到無限，例如，“1*元素”意思是至少有一個，而“1*2元素”表明允許有1個或2個。

 

［規則］（[rule]）

方括號內是可選元素。如“［元素1　元素2］”與“*1（元素1　元素2）”是一回事。

 

N　規則（N rule）

表明迴圈的次數：“（元素）”就是“*（元素）”，也就是精確指出取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字串。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 9]

 

＃規則（#rule）

“#”與“*”類似，用於定義元素列表。

 

完整形式是“#元素”表示至少有個至多有個元素，中間用“,”或任意數量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS 元素 *（ *LWS "," *LWS 元素 ））”就等同於“1#元素”。

 

空元素在結構中可被任意使用，但不參與元素個數的計數。也就是說，“（元素1），，（元素2）”僅表示2個元素。但在結構中，應至少有一個非空的元素存在。預設值是0到無限，即“#（元素）”表示可取任何數值，包括0；而“1#元素”表示至少有1個；而“1#2元素”表示有1個或2個。

 

；註釋（; comment）

  分號後面是註釋，僅在單行使用。

 

隱含*LWS（implied *LWS）

本文的語法描述是基於單詞的。除非另有指定，線性空格（LWS）可以兩個鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之間必須有至少一個分隔符，因為它們也要做為單獨的符號來解釋。實際上，應用在產生HTTP結構時，應當試圖遵照“通常方式”，因為現在的確有些實現方式在通常方式下無法正常工作。

 

2.2  基本規則（Basic Rules）

下面的規則將用於本文後面對結構基本解析。

US-ASCII 編碼字符集定義[17]。

 

OCTET    = <8-bit的順序資料，即bytes>

CHAR    = < US-ASCII字元（取值為0 – 127的OCTET）>

UPALPHA  = < US-ASCII 大寫字元"A"到"Z">

LOALPHA  =

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 10]

 

  ALPHA  = UPALPHA | LOALPHA

  DIGIT  = < US-ASCII 數字"0"到"9">

  CTL    = < US-ASCII 控制字元（取值0到31的octet ）和DEL （127）>

  CR    =

  LF    =

  SP    =

  HT    =

      =

 

HTTP/1.0規定，除實體主體（Entity-Body，見附錄B容錯應用）外，所有元素的行結束標誌都是CRLF（按位元組順序）。在實體主體內部的行結束標誌定義及其對應的介質型別定義，見3.6節的描述。

 

CRLF  = CR LF

 

HTTP/1.0的頭可以折成許多行，只要每個後續行以空格或水平製表符開頭。所有的線性空格（LWS），同空格（SP）有相同的語義。

 

LWS  = [CRLF] 1*( SP | HT )

 

實際上，有些應用並沒有考慮處理這樣多行的頭，所以從相容性上考慮，HTTP/1.0應用最好不要產生折成多行的頭。

 

TEXT規則只是用於描述訊息直譯器不關心的域的內容及其取值。文字內容可包含不同於US-ASCII的字元。

 

TEXT  =

 

在標題域中的收件人域如包含US-ASCII字符集以外的字元，這些字元將按照ISO-8859-1標準來解釋。

 

十六進位制數字型字元在幾個協議元素中到。

 

HEX  = "A" | "B" | "C" | "D" | "E" | "F"

      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

 

許多HTTP/1.0頭域的內容由被LWS分隔的單詞或特殊字元組成，這些特殊字元必須置於引號中間的字串內，作為引數值使用。

 

  = 符號（token）| 被引號引起來的字串

 

 

 

 

Berners-Lee, et al  Informational  [Page 11]

 

token  = 1*

 

tspecials    = "(" | ")" | "" | "@"

  | "," | ";" | ":" | "" |

  | "/" | "[" | "]" | "?" | "="

  | "{" | "}" | SP | HT

 

在HTTP頭域中可用括號表示註釋文字。註釋只允許寫在包含註釋的域，做為域值定義的一部分。在除此之外其它域中，括號將被視為域值。

 

comment  = "(" *( ctext | comment ) ")"

ctext    =

 

被雙引號圈中的文字字串將被視為一個單詞。

 

quoted-string  = ( *(qdtext) )

qdtext  =

 

  在HTTP/1.0中不允許使用後斜線“”來引用單字元。

 

3.  協議引數（Protocol Parameters）

 

3.1  HTTP版本（HTTP Version）

 

  HTTP採用主從（.）數字形式來表示版本。協議的版本政策傾向於讓傳送方表明其訊息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的HTTP實現通訊。只增加擴充套件域的值或增加了不影響通訊行為的訊息都不會導致版本資料的變化。當協議訊息的主要解析演算法沒變，而訊息語法及傳送方的隱含功能增加了，將會導致從版本號（）增加；當協議中訊息的格式變化了，主版本號（）也將發生改變。

  HTTP訊息的版本由訊息第一行中的HTTP版本域來表示。如果訊息中的協議版本沒有指定，接收方必須假定它是符合HTTP/0.9的簡單標準。

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 12]

 

HTTP-Version    = "HTTP" "/" 1*DIGIT "." 1*DIGIT

 

注意，主從版本應當被看作單獨的整數，因為它們都有可能增加，從而超過一位整數。因而，HTTP/2.4比HTTP/2.13版本低，而HTTP/2.13又比HTTP/12.3版本低。版本號前面的0將被接收方忽略，而在傳送方處也不應產生。

 

本文件定義了的0.9及1.0版本。傳送完整請求（Full-Request）及完整回應（Full-Response）訊息的應用必須指明HTTP的版本為“HTTP/1.0”。

 

HTTP/1.0必須：

 

o識別HTTP/0.9及HTTP/1.0請求命令中的請求佇列（Request-Line）的格式。

o理解任何HTTP/0.9及HTTP/1.0中的合法請求格式。

o 使用與客戶端相同版本的協議進行訊息回應。

 

HTTP/1.0 客戶端必須：

 

  o 識別HTTP/1.0回應中狀態佇列（Status-Line）的格式。

o 理解HTTP/0.9及HTTP/1.0中合法回應的格式。

 

  當及閘道器收到與其自身版本不同的HTTP請求時，必須小心處理請求的推送，因為協議版本表明傳送方的能力，代理或閘道器不應發出高於自身版本的訊息。如果收到高版本的請求，代理或閘道器必須降低該請求的版本，並回應一個錯誤。而低版本的請求也應在被推送前升級。

代理或閘道器回應請求時必須遵照前面列出的規定。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 13]