器端在用戶描述、請求登錄等情況下使用這類格式。
3.4  字符集（Character Sets）

	HTTP所使用的字符集定義和描述MIME時用的相同：
本文檔用字符集（character set）來指明利用一個或多個表將順序字節轉換成順序字
符的方法。注意，不需要其它方向的無條件轉換，因為不是所有的字符都可以用給
定字符集來表示，同時，一個字符集也可能提供一種以上的字節順序來表示一種特
殊的字符。這種定義傾向于允許不同類型的字符編碼通過簡單的單表映射來實現，
如，從表US-ASCII切換到復雜表如ISO2202。實際上，與MIME字符集名相關的
定義必須完整指定從字節到字符的映射，特別是不允許通過利用外部配置信息來確
定精確的映射。

注意：術語字符集（character set）歸于字符編碼（character encoding）。事實上，
由于HTTP與MIME共同使用同樣的注冊，所以其術語也應一致。
		
HTTP字符集由大小寫敏感的符號組成。全部的符號定義參見IANA字符集注冊
[15]。因為注冊處不會為每個字符集單獨定義一套符號，所以我們在這看到的字符
集名大多是與HTTP實體使用相關的。這些在RFC 1521 [5] 中注冊的字符集，即
US-ASCII [17] 及ISO-8859 [18]字符集，還有一些其它字符集被強烈建議在MIME
字符集參數內部使用。

charset = "US-ASCII"
             | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
             | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
             | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
             | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
             | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
             | token
		
雖然HTTP允許使用專用符號做為字符集值，但是任何在IANA字符集注冊表[15]
中有預定義值的符號都必須表明其所屬的字符集。應用應當將其對字符集的使用限
制在IANA注冊表規定的范圍之內。

實體主體的字符集如果屬于US-ASCII 或ISO-8859-1字符集，則勿需標記，否則，
應當用主體字符編碼方式中的最基本命名來標記。

3.5  內容譯碼（Content Codings）
	內容譯碼值用于指示對資源進行的編碼轉換。內容譯碼主要用于將經過壓縮、加密等操
作的文件進行還原，使其保持其原來的介質類型。典型情況下，經過編碼保存的資源只能經
過解碼或類似的操作才能還原。
content-coding = "x-gzip" | "x-compress" | token
	注意：出于對未來兼容性的考慮，HTTP/1.0應用應將"gzip" 和"compress" 分別與 
"x-gzip"和"x-compress"對應起來。
	所有的內容譯碼值都是大小寫敏感的。HTTP/1.0在內容編碼（10.3節）頭域中使用內
容譯碼值。雖然該值描述的是內容譯碼，但更為重要的是，它指明了應當用什么機制來進行
解碼。注意，單獨的程序可能有能力實現對多種格式編碼的解碼。
	在這段文字中，提到了兩個值：
x-gzip
文件壓縮程序"gzip" (GNU zip，由Jean-loup Gailly開發)的編碼格式。該格式屬于
典型的帶有32位CRC 校驗的Lempel-Ziv譯碼 (LZ77)。
x-compress
文件壓縮程序"compress"的編碼格式，該格式適用于LZW（Lempel-Ziv-Welch）譯
碼。
注意：用程序名來標識編碼格式的做法不是很理想，在將來可能不會繼續這樣做。現在
之所以這樣做是出于歷史的原因，并非良好的設計。

3.6  介質類型（Media Types）

	HTTP在Content-Type header域（10.5節）中使用Internet介質類型[13]，用以提供開放
的可擴展的數據類型。
media-type		= type "/" subtype *( ";" parameter )
type				= token
subtype			= token

	參數可參照屬性/值對的方式，用類型/子類型的格式來寫。

Parameter		= attribute "=" value
Attribute			= token
Value			= token | quoted-string

	其中，類型、子類型、參數屬性名是大小寫敏感的。而參數值不一定是大小寫敏感的，
這得看參數名的語法而定。在類型和子類型、屬性名和屬性值之間不能有LWS（空格）。當
接收到不能識別的介質類型的參數時，用戶代理應當忽略它們。
	一些老的HTTP應用不能識別介質類型參數，所以HTTP/1.0的應用程序只能在定義消
息內容時使用介質參數。
	介質參數（Media-type）值用Internet授權分配數字（Internet Assigned Number   
Authority ，IANA [15]）注冊。介質類型注冊過程請參見RFC1590[13]。不鼓勵使用未注冊
的介質類型。

3.6.1標準及文本缺省（Canonicalization and Text Defaults）
	Internet介質類型是用規范形式注冊的。一般來說，在通過HTTP協議傳輸實體主體
（Entity-Body）之前，必須先將其表示成適當的規范格式。如果主體用使用了一種
Content-Encoding進行編碼，下面的數據在編碼前必須轉換成規范形式：
	"text"類型的介質子類型在規范形式中使用CRLF做為文本行中斷。實際上，為和實體
主體（Entity body）內的使用方式保持一致，HTTP允許傳輸純以CR或LF單獨表示行中斷
的文本介質。HTTP應用程序必須將其通過HTTP方式接收到的文本介質中的CRLF、CR、
LF看做是行中斷符。

	另外，如果文本介質的字符集沒有使用字節13和10做為CR和LF，象一些多字節字
符集，HTTP允許使用該字符集指定的任何順序的字節替代CR和LF做為行中斷，這種行
中斷的靈活運用方式僅可于實體主體（Entity-Body）中。一個純CR或LF不應在任何HTTP
控制結構（如標題域-header field和多塊分界線-multipart boundaries）中替代CRLF。
	參數"charset"在定義數據的字符集（3.4節）時，與一些介質類型一起使用。當發送方
沒有顯式給出字符參數時，HTTP在接收時將"text"的介質子類型定義為缺省
值"ISO-8859-1"。"ISO-8859-1"字符集或其子集以外的數據必須要標記其相應的字符集值，
這樣可以保證接收方能正確地對其進行解析。
	注意：許多當前HTTP服務器提供的數據使用"ISO-8859-1"以外的其它字符集，而且也
沒有正確的進行標記，這種工作方式限制了互操作性，建議不要采用。做為一種補救方法，
一些HTTP用戶代理提供了配置選項，使用戶可以在字符集參數沒指定的情況下，自行更改
缺省的介質類型解釋方式。

3.6.2 多部分類型（Multipart Types）


	MIME提供了多部分（"multipart"）類型的數字――在一個單獨的消息實體主體
（Entity-Body）內可以封裝幾個實體（entities）。雖然用戶代理可能需要了解每種類型，從
而可以正確解釋每部分主體的意圖，但是在IANA[15]的多部分類型（multipart types）注冊
中卻找不到專為HTTP/1.0所指定的內容。HTTP用戶代理只得自己來做接收多部分類型的
工作，其過程和行為與MIME用戶代理是相同或相似的。HTTP服務器不應假定HTTP客戶
端都有能力處理多部分類型。
	
	所有的多部分類型都使用通用的語法，而且必須在介質類型值部分包括邊界參數
（boundary parameter）。消息的主體是其自身，做為協議元素，它必須只使用CRLF做為段
間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對各段有重要意
義的HTTP標題域。

3.7  產品標識（Product Tokens）
	是通訊應用程序用來標識其自身的一個簡單符號，常和任意字母及版本描述一起使用。
大多數產品標識也將其產品的重要組成部分的版本號一起列出，中間用空格分隔。

	按慣例，在標識應用程序時，組件以其重要性順序排列。
Product			= token ["/" product-version]
product-version 	= token
例如：
       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
       Server: Apache/0.8.4
	產品標識應當短小，因而禁止利用該域填寫廣告或其它無關信息。雖然任何符號字符都
可能出現在產品版本中，該符號應當只用于做版本定義，也就是說，同一個產品的連續版本
之間只能通過產品版本值進行區分。

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）都使用RFC822[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

| 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		= <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, tspecials, and quoted-string>
標題域接收的順序并不重要，但良好的習慣是，先發送主標題，然后是請求標題或回應
標題，最后是實體標題。
	當且僅當標題域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名
的HTTP標題域才可以表示在一個消息里。而且必須能在不改變消息語法的前提下，將并發
的域值加到第一個值后面，之間用逗號分隔，最終能將多個標題域結合成“域名：域值”對。

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

	注意，簡單請求與完整請求的請求隊列之間的區別在于是否有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）格式只在代理（proxy）在產生請求時使用。代理的責任是將
請求向前推送，并將回應返回。如果請求是GET或HEAD方式，而且之前的回應被緩存，
如果代理忽略標題域的過期信息限制，它可能使用緩存中的消息。注意，代理可能將請求推
送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的服務器。為了避免請求
循環，代理必須能夠識別它的所有服務器名，包括別名、本地變量及數字形式的IP地址。
下面是一個請求隊列的例子：

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0

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

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