BNF）包括下面的結構：

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

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

規則1｜規則2（rule1 | rule2）
		“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。

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

*規則（*rule）
在元素前加星號“*”表示循環，其完整形式是“<n>*<m>元素”，表明元素最少產
生<n>次，最多<m>次。缺省值是0到無限，例如，“1*元素”意思是至少有一個，
而“1*2元素”表明允許有1個或2個。

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

N　規則（N rule）
表明循環的次數：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>
取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字符串。

＃規則（#rule）
“#”與“*”類似，用于定義元素列表。

完整形式是“<n>#<m>元素”表示至少有<n>個至多有<m>個元素，中間用“,”或
任意數量的空格（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		= <US-ASCII 小寫字符"a"到"z">

       ALPHA		= UPALPHA | LOALPHA
       DIGIT		= < US-ASCII 數字"0"到"9">
       CTL			= < US-ASCII 控制字符（取值0到31的octet ）和DEL （127）>
       CR			= <US-ASCII CR, 回車符carriage return（13）>
       LF			= <US-ASCII LF, 換行符linefeed （10）>
       SP			= <US-ASCII SP, 空格space （32）>
       HT			= <US-ASCII HT, 水平制表符horizontal-tab（9）>
       <">			= <US-ASCII 雙引號標記double-quote mark （34）>

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		= <除了控制字符（CTLs）之外的任何OCTET，包括LWS >
		
在標題域中的收件人域如包含US-ASCII字符集以外的字符，這些字符將按照
ISO-8859-1標準來解釋。

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

HEX		= "A" | "B" | "C" | "D" | "E" | "F"
        			| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

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

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

token		= 1*<除控制字符（CTLs）或tspecials之外的任意字符>

tspecials	    = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT
		
在HTTP頭域中可用括號表示注釋文字。注釋只允許寫在包含注釋的域，做為域值
定義的一部分。在除此之外其它域中，括號將被視為域值。

comment		= "(" *( ctext | comment ) ")"
ctext			= <除圓括號外的任何TEXT>

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

quoted-string	= ( <"> *(qdtext) <"> )
qdtext		= <除了雙引號及控制字符之外的任何字符，包括LWS >

		在HTTP/1.0中不允許使用后斜線“\”來引用單字符。

3.  協議參數（Protocol Parameters）
3.1  HTTP版本（HTTP Version）
	
	HTTP采用主從（<major>.<minor>）數字形式來表示版本。協議的版本政策傾向于讓發
送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高
版本的HTTP實現通訊。只增加擴展域的值或增加了不影響通訊行為的消息組件都不會導致
版本數據的變化。當協議消息的主要解析算法沒變，而消息語法及發送方的隱含功能增加了，
將會導致從版本號（<minor>）增加；當協議中消息的格式變化了，主版本號（<major>）也
將發生改變。
	HTTP消息的版本由消息第一行中的HTTP版本域來表示。如果消息中的協議版本沒有
指定，接收方必須假定它是符合HTTP/0.9的簡單標準。

HTTP-Version		= "HTTP" "/" 1*DIGIT "." 1*DIGIT
		
注意，主從版本應當被看作單獨的整數，因為它們都有可能增加，從而超過一位整
數。因而，HTTP/2.4比HTTP/2.13版本低，而HTTP/2.13又比HTTP/12.3版本低。
版本號前面的0將被接收方忽略，而在發送方處也不應產生。
		
本文檔定義了HTTP協議的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請求時，必須小心處理請求的推送，因為
協議版本表明發送方的能力，代理或網關不應發出高于自身版本的消息。如果收到高版本的
請求，代理或網關必須降低該請求的版本，并回應一個錯誤。而低版本的請求也應在被推送
前升級。
代理或網關回應請求時必須遵照前面列出的規定。

3.2  統一資源標識（Uniform Resource Identifiers）

	URI有許多名字，如WWW地址、通用文件標識（Universal Document Identifiers）、通
用資源標識（Universal Resource Identifiers [2]），以及最終的統一資源定位符（Uniform 
Resource Locators (URL) [4]）和統一資源名（URN）。在涉及HTTP以前，URI用簡單格式
的字符串描述－名字、位置、或其它特性，如網絡資源。

3.2.1 一般語法（General Syntax）
	在HTTP中URI可以用絕對形式表示，也可用相對于某一基本URI[9]的形式表示，具
體取決于它們的使用方式。這兩種形式的不同在于絕對URI總是以方法名稱后跟“：”開頭。

       URI			= ( absoluteURI | relativeURI ) [ "#" fragment ]

       absoluteURI	= scheme ":" *( uchar | reserved )

       relativeURI	= net_path | abs_path | rel_path

       net_path       = "//" net_loc [ abs_path ]
       abs_path       = "/" rel_path
       rel_path       = [ path ] [ ";" params ] [ "?" query ]

       path           = fsegment *( "/" segment )
       fsegment       = 1*pchar
       segment        = *pchar

       params         = param *( ";" param )
       param          = *( pchar | "/" )

       scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
       net_loc        = *( pchar | ";" | "?" )
       query          = *( uchar | reserved )
       fragment       = *( uchar | reserved )

       pchar          = uchar | ":" | "@" | "&" | "=" | "+"
       uchar          = unreserved | escape
       unreserved     = ALPHA | DIGIT | safe | extra | national

       escape         = "%" HEX HEX
       reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
       extra          = "!" | "*" | "'" | "(" | ")" | ","
       safe           = "$" | "-" | "_" | "."
       unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
       national       = <any OCTET excluding ALPHA, DIGIT,


                        reserved, extra, safe, and unsafe>
	權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。上面所提到的BNF中
包括了合法URL中不允許出現的符號（RFC1738），因為HTTP服務器并沒有限制為只能用
非保留字符集中的字符來表示地址路徑，而且HTTP代理也可能接收到RFC1738沒有定義
的URI請求。

3.2.2 http URL

“http”表示要通過HTTP協議來定位網絡資源。本節定義了HTTP URL的語法和語義。

       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

host           = <合法的Internet主機域名或IP地址（用十進制數及點組成）
，見RFC1123，2.1節定義>

       port           = *DIGIT

	如是端口為空或沒指定，則缺省為80端口。對于絕對路徑的URI來說，擁有被請求的
資源的服務器主機通過偵聽該端口的TCP連接來接收該URI請求。如果URL中沒有給出
絕對路徑，要作為請求URI（參見5.1.2節）使用，必須以“/”形式給出。

	注意：雖然HTTP協議獨立于傳輸層協議，http URL只是標識資源的TCP位置，而對
于非TCP資源來說，必須用其它的URI形式來標識。
	
	規范的HTTP URL形式可通過將主機中的大寫字符轉換成小寫（主機名是大小寫敏感
的）來獲得。如果端口是80，去掉冒號及端口號，并將空路徑替換成“/”。

3.3  Date/Time 格式（Date/Time Formats）

	出于歷史原因，HTTP/1.0應用允許三種格式來表示時間戳：

       Sun, 06 Nov 1994 08:49:37 GMT    ; RFC 822, updated by RFC 1123
       Sunday, 06-Nov-94 08:49:37 GMT   ; RFC 850, obsoleted by RFC 1036
       Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

	第一種格式是首選的Internet標準格式，表示方法長度固定（RFC1123[6]）。第二種格
式在普通情況下使用，但是它是基于已經廢棄的RFC850[10]中的日期格式，而且年不是用
四位數字表示的。HTTP/1.0 客戶端及服務器端在解析日期時可識別全部三種格式，但是它
們不可以產生第三種時間格式(asctime) 。
	注意：對于接收到由非HTTP應用產生的日期數據時，提倡對接收到的日期值進行填充。
這樣做是因為，在某些時候，代理或網關可能通過SMTP或NNTP來獲取或發送消息。
	所有的HTTP/1.0 date/timp時間戳必須用世界時間（Universal Time，UT），即格林威治
時間來表示（Greenwich Mean Time，GMT），沒有任何修改的余地。前面的兩種格式用了
“GMT”表示時區，在讀ASC表示的時間時，也應假定是這個時區。

HTTP-date	= rfc1123-date | rfc850-date | asctime-date

rfc1123-date	= wkday "," SP date1 SP time SP "GMT"
rfc850-date	= weekday "," SP date2 SP time SP "GMT"
asctime-date	= wkday SP date3 SP time SP 4DIGIT
date1		= 2DIGIT SP month SP 4DIGIT
                    　; day month year (e.g., 02 Jun 1982)
date2		= 2DIGIT "-" month "-" 2DIGIT
                      ; day-month-year (e.g., 02-Jun-82)
date3		= month SP ( 2DIGIT | ( SP 1DIGIT ))
                      ; month day (e.g., Jun  2)
time			= 2DIGIT ":" 2DIGIT ":" 2DIGIT
                      ; 00:00:00 - 23:59:59
wkday		= "Mon" | "Tue" | "Wed"
                      | "Thu" | "Fri" | "Sat" | "Sun"
weekday		= "Monday" | "Tuesday" | "Wednesday"
                      | "Thursday" | "Friday" | "Saturday" | "Sunday"
month		= "Jan" | "Feb" | "Mar" | "Apr"
                      | "May" | "Jun" | "Jul" | "Aug"
                      | "Sep" | "Oct" | "Nov" | "Dec"
注意：HTTP要求只能在協議流中使用data/time時間戳格式，不要求客戶端及服務