說明

   本文件規定了網際網路社群的標準組協議，並需要討論和建議以便更加完善。請參考

“網際網路官方協議標準”（STD 1）來了解本協議的標準化狀態。本協議不限流傳發布。

   Copyright （C） The Internet Society （1999）.   All Rights Reserved.

摘要

超文字傳輸協議（HTTP）是一種為分散式，合作式，多媒體資訊系統服務，面向 應用層的協議。它是一種通用的，不分狀態（stateless）的協議，除了諸如名稱服務和分佈物件管理系統之類的超文字用途外，還可以通過擴充套件它的請求方式，錯誤程式碼和報頭[47]來 完成許多工。

HTTP在1990年WWW全球資訊剛剛起步的時候就得到了應用。本說明書詳細闡述了HTTP/1.1 協議，是RFC 2068的修訂版[33]。

HTTP的發展是全球資訊網協會和Internet工作小組合作的結果，在一系列的RFC釋出了最終的版本，其中最著名的是RFC 2616（http://tools.ietf.org/html/rfc2616）。在RFC 2616中定義了HTTP 1.1這個今天普遍使用的版本。

1 引論

1.1 目的

超文字傳輸協議（HTTP）是一種為分散式，合作式，多媒體資訊系統服務，面向應用層的

這裡規定的協議叫做擧TTP/1.1".這個協議與HTTP/1.0相比，要求更為嚴格，以確保各項功能得到可靠實現。

實際的資訊系統除了簡單的檢索外，要求更多的功能性（functionality），包括查詢（search），前端更新（front-end update）和註解（annotation）。HTTP允許可擴充的方法集和報頭集以指示請求的目的[47]。它是建立在統一資源識別符號（URI）[3]提供的地址（URL）[4]和名字（URN）上[20]，以指出方法應用於哪個資源的。訊息以類似於一種叫做多用途網路郵件擴充套件（MIME）[7] 的網際網路郵件的格式傳送。

HTTP也是用於使用者代理之間及代理/閘道器到其他網路系統的通用通訊協議，這樣的網路系統可能由SMTP[16],NNTP[13],FTP[18],Gopher[2]和WAIS[10]協議支援。這樣，HTTP允許不同的應用程式對資源進行基本的超媒體訪問。

1.2 要求

本文的關鍵詞"MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL"將由RFC 2119[34]解釋。

一個應用程式如果不能滿足協議提供的一個或多個MUST或REQUIRED等級的要求，是不符合要求的。一個應用程式如果滿足所有MUST或REQUIRED等級以及所有SHOULD等級的要求，則被稱為非條件遵循（unconditionally compliant）的；若滿足所有MUST等級的要求但不能滿足所有SHOULD等級的要求則被稱為條件遵循的（conditionally compliant）。

1.3 術語

本說明用到了若干術語，以表示HTTP通訊中各參與者和物件扮演的不同角色。

連線（connection）

為通訊而在兩個程式間建立的傳輸層虛擬電路。

訊息（message）

HTTP通訊中的基本單元。它由一個結構化的八位元位元組序列組成，與第4章定義的句法相匹配，並通過連線得到傳送。

請求（request）

一種HTTP請求訊息，參看第5章的定義。

響應（response）

一種HTTP響應訊息，參看第6章的定義。

資源（resource）

一種網路資料物件或服務，可以用第3.2節定義的URI指定。資源可以以多種表現方式（例如多種語言，資料格式，大小和解析度）或者根據其它方面而而不同的表現形式。

實體（entity）

實體是請求或響應的有效承載資訊。一個實體包含元資訊和內容，元資訊以實體頭域（entity-header field）形式表示，內容以訊息主體（entity-body）形式表示。在第7節詳述。

表現形式 （representation）

一個響應包含的實體是由內容協商（content negotiation）決定的。如第12章所述。有可能存在一個特定的響應狀態碼對應多個表現形式。

內容協商（content negotiation）

當服務一個請求時選擇資源的一種適當的表示形式的機制（mechanism），如第12節所述。任何響應裡實體的表現形式都是可協商的（包括出錯響應）.

變數（variant）

在任何給定時刻，一個資源對應的表現形式（representation）可以有一個或多個（譯註：一個URI請一個資源，但返回的是此資源對應的表現形式，這根據內容協商決定）。每個表現形式（representation）被稱作一個變數。使用變數這個術語並不是意味著資源（resource）是必須由內容協商決定的.

客戶端（client）

為傳送請求建立連線的程式.

使用者代理（user agent）

初始化請求的客戶端程式。常見的如瀏覽器,編輯器,蜘蛛（網路穿越機器人）,或其他的終端使用者工具.

伺服器（Server）

伺服器是這樣一個應用程式，它同意請求端的連線，併發送響應（response）。任何給定的程式都有可能既做客戶端又做伺服器；我們使用這些術語是為了說明特定連線中應用程式所擔當的角色，而不是指通常意義上應用程式的能力。同樣，任何伺服器都可以基於每個請求的性質扮演源伺服器，代理，閘道器，或者隧道等角色之一。

源伺服器（Origin server）

存在資源或者資源在其上被建立的伺服器（server）被成為源伺服器（origin server）。  

代理（ Proxy）

代理是一箇中間程式，它既擔當客戶端的角色也擔當伺服器的角色。代理代表客戶端向伺服器傳送請求。客戶端的請求經過代理，會在代理內部得到服務或者經過一定的轉換轉至其他伺服器。一個代理必須能同時實現本規範中對客戶端和伺服器所作的要求。透明代理（transparent proxy）需要代理授權和代理識別，但不修改請求或響應。非透明代理（non-transparent  proxy）需修改請求或響應，以便為使用者代理（user agent）提供附加服務，附加服務包括組註釋服務，媒體型別轉換，協議簡化，或者匿名過濾等。除非透明行為或非透明行為經明確指出，否則，HTTP代理既是透明代理也是非透明代理。

閘道器（gateway）

閘道器其實是一個伺服器，扮演著代表其它伺服器為客戶端提供服務的中間者。與代理（proxy）不同，閘道器接收請求，彷彿它就是請求資源的源伺服器。請求的客戶端可能覺察不到它正在同閘道器通訊。

隧道（tunnel）

隧道也是一箇中間程式，它一個在兩個連線之間充當盲目中繼（blind relay）的中間程式。一旦隧道處於活動狀態，它不能被認為是這次HTTP通訊的參與者，雖然HTTP請求可能已經把它初始化了。當兩端的中繼連線都關閉的時候，隧道不再存在。

快取（cache）

快取是程式響應訊息的本地儲存。快取是一個子系統，控制訊息的儲存、取回和刪除。快取裡存放可快取響應（cacheable response）為的是減少對將來同樣請求的響應時間和網路頻寬消耗。任一客戶端或伺服器都可能含有快取，但快取記憶體不能被一個充當隧道（tunnel）的伺服器使用。

可快取（cacheable）

我們可以說響應（response）是可快取的，如果一個快取（cache）為了響應後繼請求而被允許儲存響應訊息（response message）的副本。確定HTTP響應的快取能力（cacheability）在13節中有介紹。即使一個資源（resourse）是可快取的，也可能存在快取是否能利用快取副本的約束。 

第一手的（first-hand）

如果一個響應直接從源伺服器或經過若干代理（proxy），並且沒有不必要的延時，最後到達客戶端，那麼這個響應就是第一手的（first-hand）。

如果響應被源伺服器（origin server）驗證是有效性（validity）的，那麼這個響應也同樣是第一手的。

明確過期時間（explicit expiration time）     

是源伺服器希望實體（entity）如果沒有被進一步驗證（validation）就不要再被快取（cache）返回的時間。

啟發式過期時間（heuristic expiration time）      

當沒有明確終止時間（explicit expiration time）可利用時，由快取所指定的終止時間.

年齡（age）

 一個響應的年齡是從被源伺服器傳送或被源伺服器成功確認的時間點到現在的時間。

保鮮壽命（freshness lifetime）

一個響應產生的時間點到過期時間點之間的長度。

保鮮（Fresh）    

如果一個響應的年齡還沒有超過保鮮壽命（freshness lifetime），它就是保鮮的.

陳舊（Stale）

一個響應的年齡已經超過了它的保鮮壽命（freshness lifetime），就是陳舊的.

語義透明（semantically transparent）

快取（cache）可能會以一種語意透明（semantically transparent）的方式工作。這時，對於一個特定的響應，使用快取既不會對請求客戶端產生影響也不會對源伺服器產生影響，快取的使用只是為了提高效能。當快取（cache）具有語意透明性時，客戶端從快取接收的響應跟直接從源伺服器接收的響應完全一致（除了使用hop-by-hop頭域）。

驗證器（Validator）

驗證器其實是協議元素（例如：實體頭（entity tag）或最後更改時間（last-modified time）等），這些協議元素被用於識別快取裡儲存的資料（即快取項）是否是源伺服器的實體的副本。

上游/下游（upstream/downstream）

上游和下游描述了訊息的流動:所有訊息都從上游流到下游.

向內/向外（inbound/outbound）

向內和向外指的是訊息的請求和響應路徑:"向內"即"移向源伺服器","向外"即"移向使用者代理（user agent）".

1.4 總體操作

HTTP協議是一種請求/響應協議。 與伺服器建立連線後，客戶端以請求方法，URI和協議版本號，然後緊接著跟隨一個類MIME（MIME-like）訊息，這個類MIME訊息包括請求修飾符，客戶資訊和可能的訊息主體。伺服器以一個狀態行並跟隨一個類MIME（MIME-like）訊息響應，狀態行包含訊息的協議版本和成功出錯的狀態碼，類MIME訊息包含伺服器資訊，實體元資訊，和可能的實體。HTTP和MIME之間的關係如附錄19.4節所闡述。

大部分的HTTP通訊是由使用者代理（user agent）開始的，由應用到一個需要源伺服器資源的請求構成。最簡單的情形，可以經使用者代理（UA）和源伺服器（O）之間的單一連線（v）完成。

請求鏈（Request chain）--------------------- ----------à

使用者代理（UA）----------------單一連線（v）--------------源伺服器（O）

<---------------------------------------響應鏈（response chain）

當一個或多箇中間者在請求/響應鏈中出現的時候，會出現更復雜的情形。常見的中間者有三種：代理（proxy），閘道器（gateway）和隧道（tunnel）。代理（proxy）是一種前向代理（a  forwarding  agent），它接收絕對URI（absoulute url，相對於相對url）請求，重寫全部或部分訊息，然後把格式化後的請求傳送到URI指定的伺服器上。閘道器是一種接收代理（receiving agent），它充當一個層（layer），這個層在伺服器之上，必要時它會把請求翻譯成為下層伺服器的協議。隧道不改變訊息而充當兩個連線之間的中繼點；它用於通訊需要穿過中間者（如防火牆）甚至當中間者不能理解訊息內容的時候。

請求鏈（request chain）----------------------------------------à

UA-----v-----A-----v-----B-----v-----C------------v-----------------O

 <----------------------------------------響應鏈（response chain）

上圖顯示了使用者代理（user agent）和源伺服器之間的三個中間者（A，B和C）。整條鏈的請求或響應將會通過四個單獨的連線。這個特性很重要，因為某些HTTP通訊選項可能只能應用於與最近的非隧道鄰接點的連線，只能應用於鏈的端點（end-point）的連線，或者能應用於此鏈的所有連線。圖表儘管是線性的，每個參與者可能忙於多路同時通訊。例如，B可以接收來自不同於A的許多客戶的請求，並且／或者可以把請求轉到不同於C的伺服器，與此同時，它還在處理A的請求。

任何非隧道的通訊成員都可能會採用一個內部快取（cache）來處理請求。如果沿著鏈的通訊成員對請求採用了快取響應，請求/響應鏈就會大大縮短。下圖闡明瞭一個最終請求響應鏈，這是在假定B擁有一個來自O（通過C）的以前請求的響應副本，但此響應尚未被UA或A快取。

請求鏈（request chain）---------->

UA-----v----------A-----v-----B-----C----O

<---------響應鏈 （response chain）

並不是所有的響應都能有效地快取，一些請求可能含有修飾符，這些修飾符對快取動作有特殊的要求。快取動作和快取響應的HTTP行為要求將在第13節定義。

實際上，目前全球資訊網上有多種結構和配置的快取（cache）和代理（proxy）正在被使用。這些系統包括節省頻寬的快取代理（proxy cache），可以廣播或多點傳送快取資料的系統，通過CD-ROM分配快取資料子集的機構，等等。HTTP系統（http system）會被應用於寬頻連線的企業區域網中的協作，並且可以通過PDA進行低耗無線的，斷續連線的訪問。HTTP1.1的宗旨是為了支援各種各樣的已經部署的配置，同時引進一種協議結構，讓它滿足那些需要較高可靠性，即使不能達到較高可靠性的要求，也要也讓它至少可以指示故障的網路應用的要求。

HTTP通訊通常發生在TCP/IP連線上。預設埠是TCP 80，不過其它埠也可以使用。這並不妨礙HTTP的實現被應用於網際網路（internt）或其它網的協議之上。Http僅僅期望的是一個可靠的傳輸（譯註：HTTP一般建立在傳輸層協議之上）；任何提供這種保證的協議都可以被使用；協議傳輸資料單元（transport data unit）與HTTP/1.1請求和響應的訊息結構之間的映象已經超出了本說明書的範圍。

大部分HTTP/1.0的實現都是針對每個請求/響應交換產生一個新的連線。而http/1.1中，一個連線可以被用於一個或更多請求/響應交換，雖然連線可能會因為各種原因中斷（見第8.1節）。

2 符號習慣和一般語法

2.1 擴充的BNF（擴充的 巴科斯-諾爾正規化）

本文件規定的所有機制都用兩種方法描述：散文體（prose）和類似於RFC 822的擴充Backus-Naur Form（BNF）。要理解本規範，使用者需熟悉符號表示法。擴充BNF結構如下：

名字（name）=定義（definition）

名字（name）就是代表規則的名字（譯註：如：CRLF，DIGIT等等都是規則名），規則名裡不能包含“<”和“>”，通過等於號把規則名和規則定義（definiation）分離開。空白（white space）是有意義的，因為可以用縮排（indentation，譯註：縮排就是空白，後面會講到LWS） 把規則定義顯示成多行。某些基本規則（basic rule，譯註：2.2節說明基本規則的語法）使用大寫字母包含在規則定義裡，如SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。尖括號可以包含在規則定義裡，只要它們的存在有利於識別規則名（譯註：LWS，HT等都是規則名）。

“字面文字”（“literal”）

字面文字（literal text）兩邊用引號。除非宣告，字面文字大小寫不敏感（譯註：如，HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 裡的A，B,C，D等等都是字面文字（literal text））。

規則1 | 規則2

由豎線（“|”）分開的元素是可選的，例如，“yes | no”表示yes或no都是可接受的。

（規則1 規則2）

圍在括號裡的多個元素視作一個元素。所以，“（elem （foo | bar） elem）”的符合的字串是“elem foo elem”和“elem bar elem”。

*規則

前面的字元“*”表示重複。完整的形式是“<n>*<m>元素”，表示元素至少出現<n>次，至多出現<m>次。預設值是0和無窮大，所以"*（元素）"允許任何數值，包括零；"1*元素"至少需要一次；"1*2element"允許一次或兩次。

[規則]

方括號裡是任選元素；“[foo bar]”相當於“*1（foo bar）”。

N 規則

特殊的重複：“<n>（元素）”與“<n>*<n>（元素）”等價；就是說，（元素）正好出現了<n>次。這樣2DIGIT是一個兩位數字，3ALPHA是一個由三個字元組成的字串。

#規則

類似於“*”，結構“#”是用來定義一系列元素的。完整的形式是<n>#<m>元素，表示至少<n>個元素，至多<m>個元素，元素之間被一個或多個逗號（“,”）以及可選的線性空白（LWS）隔開了。這就使得表示列表這樣的形式變得非常容易；像

（ *LWS element） *（ *LWS ","*LWS element ））

就可以表示為

1#element  

無論在哪裡使用這個結構，空元素都是允許的，但是不計入元素出現的次數。換句話說 ，

“（element ）, , （element）  ”是允許的，但是僅僅視為兩個元素。因此，在至少需要一個元素的地方，必須存在至少一個非空元素。預設值是0和無窮大，這樣，“#element”允許任意零個或多個元素；“1# element”需要至少一個；“1#2element”允許一個或兩個元素。

；註釋（comment）

用分號引導註釋。

隱含的（implied） *LWS

本說明書所描述的語法是基於字的。除非特別註明，線性空白可出現在任何兩個相鄰字之間（標記（token）或引用字串（quoted-string）），以及相鄰字和間隔符之間，這並沒有改變一個域的解釋。任何兩個標記（token）之間必須有至少一個分割符，否則將會被理解為單一標記。

2.2基本規則 （basic rule）

下面的規則貫穿於本規範的全文，此規則描述了基本的解析結構。US-ASCII（美國資訊交換標準碼）編碼字符集是由ANSI X3.4-1986[21]定義的。 

       OCTET（位元組）    = <任意八位元的資料序列>

       CHAR           = <任意ASCII字元（ascii碼值從 0到127的位元組）>

       UPALPHA        = <任意大寫字母"A"..."Z">

       LOALPHA        = <任意小寫字母"a"..."z">

       ALPHA          = UPALPHA | LOALPHA 

       DIGIT          = <任意數字0，1，...9>

       CTL          = <任意控制字元（ascii碼值從0 到 31的位元組）及刪除鍵DEL（127>

       CR             = <US-ASCII CR, 回車（13）>

       LF             = <US-ASCII LF, 換行符（10）>

       SP             = <US-ASCII SP, 空格（32）>

       HT             = <US-ASCII HT, 水平製表 （9）>

       <">            = <US-ASCII 雙引號（34）>

HTTP/1.1將 CR LF 的序列定義為任何協議元素的行尾標誌，但這除了實體主體（endtity-body）外（要求比較鬆的應用見附錄19.3）。實體主體（entity-body）的行尾標誌是由它的關聯媒體型別定義的，如3.7節所述。

       CRLF           = CR LF

HTTP/1.1 的訊息頭域值可以摺疊成多行，但緊接著的摺疊行由空格（SP）或水平製表（HT）摺疊標記開始。所有的線性空白（LWS）包括摺疊行的摺疊標記（空格SP或水平製表鍵HT），具有同SP一樣的語義。接收者在解析域值或將訊息轉送到下游（downstream）之前可能會將任何線性空白（LWS）替換成單個SP（空格）。

       LWS            = [CRLF] 1*（ SP | HT ）

下面的TEXT規則僅僅適用於域內容和域值的描述，不會被訊息直譯器解析。TEXT裡的字可以包含不僅僅是ISO-8859-1[22]裡的字符集，也可以包含RFC 2047裡規定的字符集。

       TEXT           = <除CTLs以外的任意OCTET，但包括LWS>

一個CRLF只有作為HTTP訊息頭域延續的一部分時才在TEXT定義裡使用。

十六進位制數字字元用在多個協議元素（protocol element）裡。

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

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

許多HTTP/1.1的訊息頭域值是由LWS或特殊字元分隔的字構成的。這些特殊字元必須先被包含在引用字串（quoted string）裡之後才能用於引數值（如3.6節定義）裡。

       token （標記）        = 1*<除CTLs與分割符以外的任意 CHAR >

       separators（分割符）    = "（" | "）" | "<" | ">" | "@"

                               | "," | ";" | ":" | """ | <">

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

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

通過用圓括號括起來，註釋（comment）可以包含在一些HTTP頭域裡。註釋只可以作為域定義的一部分。在其他域裡，圓括號被視作域值的一部分。

       comment （註釋）= "（" *（ ctext | quoted-pair | comment ） "）"

       ctext          = <除"（" 和 "）"以外的任意TEXT >

如果一個TEXT若被包含在雙引號裡，則當作一個字。

       quoted-string = （ <"> *（qdtext | quoted-pair ） <"> ）

qdtext       = <any TEXT except <">>

斜劃線（"""）可以被作為單個字元的引用機制，但是必須要在引號和註釋區之內。

quoted-pair = """ CHAR

3 協議引數

3.1 HTTP版本

HTTP使用一個“<major>.<minor>”數字模式來指明協議的版本號。協議的版本號是為了讓傳送端指明訊息的格式和它的能力，這是為了進一步的HTTP通訊，而不僅僅是獲得通訊的特徵。協議版本是不需要修改的，當訊息元件的增加不會影響通訊行為或著只增加了擴充套件的域值。<minor>數字是遞增的，當協議會因為新增一些特徵而做了修改的時候。但這些變化不會影響通常的訊息解析演算法，但是它會給訊息新增語意（semantic）並且會暗示傳送者具有額外的能力。<major>數字也是不斷遞增的，當協議的訊息格式每次發生變化時。

HTTP訊息的版本在HTTP-Version域被指明，HTTP-Version域在訊息的第一行中。

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

注意major和minor數字必須被看成兩個獨立整數，每個整數都可以遞增，並且可以增大到大於一位數的整數，如HTTP/2.4比HTTP/2.13低，而HTTP/2.4又比HTTP/12.3低。前導0必須被接收者忽略並且不能被髮送者傳送。

一個應用程式傳送請求或響應訊息，如果請求或響應訊息裡的HTTP-Version是”HTTP/1.1”，那麼此應用程式必須條件遵循此協議規範。最少條件遵循此規範的應用程式應該把”HTTP/1.1”包含在他們的訊息裡，並且對任何不相容HTTP/1.1的訊息必須這麼做。關於何時傳送特定的HTTP-Version值的細節，參見RFC2145。

應用程式的HTTP版本是應用程式最少條件遵循的最高HTTP版本。

代理（proxy）和閘道器（gateway）應用程式需要被仔細對待，當轉發（forwarding）訊息的協議版本不同於代理或閘道器應用程式的協議版本。因為訊息裡協議版本說明了傳送者處理協議的能力，所以一個代理/閘道器千萬不要傳送一個高於該代理/閘道器應用程式協議版本的訊息。如果代理或閘道器接收了一個更高版本的訊息，它也必須要降低請求的版本，要麼以一個錯誤響應，要麼切換到隧道行為（tunnel behavior）。

由於自從RFC 2068[33]釋出後，產生了與HTTP/1.0代理（proxy）的互操作問題，所以快取代理（caching proxy）必須能改變請求（request），使請求能到達他們能支援的最高版本，但閘道器（gateway）可以這麼做也可以不這麼做，而tunnel不能這麼做。代理（Proxy）/閘道器（gateway）的響應（Response）必須和請求（request）的HTTP版本的major數字相同。

注意：在HTTP版本間的轉換可能包含頭域（header field）的改變，而這些改變會可能會根據HTTP版本而被要求或被拒絕。

3.2 統一資源識別符號（URI）

URIs的許多名字已為人所知：WWW地址，通用文件識別符號，通用資源識別符號[3]，以及後來的統一資源定位器（URL）[4]和統一資源名稱（URN）[20]。就HTTP而言，統一資源定位器只是格式化的字串，它通過名稱，地址，或任何別的特徵識別資源。

3.2.1一般語法

根據使用的背景，HTTP裡的URI可以表示成絕對（absoulute）形式或相對形式（相對於已知的URL）。兩種形式的區別是根據這樣的事實：絕對URI總是以一個方案（scheme）名作為開頭，其後是一個冒號。關於URL更詳盡的資訊請參看"統一資源識別符號（URI）:一般語法和語義"，RFC 2396 [42]（代替了RFCs 1738 [4]和RFC 1808 [11]）。本規範採用了RFC 2396裡的"URI-reference"，"absoluteURI"，"relativeURI"，"port"，"host"，"abs_path"，"rel_path",和"authority"的定義格式。

HTTP協議不對URI的長度作事先的限制，伺服器必須能夠處理它們資源的URI，並且應該能夠處理無限長度的URI，這種無效長度的URL可能會在客戶端以GET形式的請求產生。伺服器應該返回414狀態碼（此狀態碼代表Request-URI太長），如果伺服器不能處理太長的URI的時候。

注:伺服器在依賴大於255位元組的URI時應謹慎，因為一些舊的客戶或代理實現可能不支援這些長度。

3.2.2 http URL

通過HTTP協議，http方案（http scheme）被用於定位網路資源（resourse）的位置。本節定義了這種方案的語法和語義。

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

如果埠為空或未給出，就假定為80。語義即：已識別的資源放在伺服器上，在那臺主機的那個埠上監聽TCP連線。這時資源的請求的URI為絕對路徑（5.1.2節）。無論什麼可能的時候，URL裡使用IP地址都是應該避免的（參看RFC 1900 [24]）。如果絕對地址（abs_path）沒有出現在URL裡，那麼應該給出"/"。如果代理（proxy）收到一個主機（host）名，但是這個主機名不是全稱的域名（fully quanlified domain name），則代理應該把它的域名加到主機名上。如果代理（proxy）接收了一個全稱的域名，代理不必改變主機。

3.2.3 URI 比較

當比較兩個URI是否匹配時，客戶應該對整個URI比較時應該區分大小寫，並且一個位元組一個位元組的比較。 但下面有些特殊情況：

- 一個為空或未給定的埠等同於URI-refernece（見RFC 2396）裡的預設埠;

- 主機（host）名的比較必須不必分大小寫;

- 方案（scheme）名的比較必須是不區分大小寫的;

- 一個空絕對路徑（abs_path）等同於"/"。

除了"保留（reserved）"和"不安全（unsafe）"字符集裡的字元（參見RFC 2396 [42]） ，其它字元都等效於它們的"%HEXHEX"編碼.  

例如,以下三個URI是等同的:

      http://abc.com:80/~smith/home.html

      http://ABC.com/%7Esmith/home.html

      http://ABC.com:/%7esmith/home.html

3.3 日期/時間格式（Date/Time Formats）

3.3.1完整日期 （Full Date）

 HTTP應用曾經一直允許三種不同日期/時間格式：

      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標準提出來的，它是一個國定長度的，由RFC 1123 [8]（RFC 822[9]的升級版本）定義的一個子集。第二種格式使用比較普遍，但是基於廢棄的RFC 850 [12]，並且沒有年份。如果HTTP/1.1客戶端和伺服器解析日期，他們必須能接收所有三種格式（為了相容HTTP/1.0），但是它們只能產生RFC 1123裡定義的日期格式來填充頭域（header field）用到日期的地方。

注:日期值的接收者被鼓勵能健壯的接收可能由非HTTP應用發來的日期值，例如有時可以通過代理（proxy）/閘道器（gateway）向SMTP或NNTP獲得或轉發訊息。

所有的HTTP日期/時間都必須以格林威治時間（GMT）表示。對HTTP而言，GMT完全等同於UTC（世界協調時間）。前兩種日期/時間格式裡包含“GMT”，它是時區的三個字面的簡寫，並且當讀到一個asctime格式時必須先被假定是GMT時間。HTTP日期（HTTP-date）區分大小寫，不能包含一個額外的LWS，除非此LWS作為在下面的Http-date語法中指定的SP。

       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對日期/時間格式的要求僅僅應用在協議的訊息（譯註:原文是protocol stream，便於理解這裡譯作訊息）裡。客戶和伺服器不必把這種格式應用於使用者呈現（user presentation