8.? 方法定義（Method Definitions）

通用的HTTP/1.0的方法集將在下面定義交播，雖然該方法集可以擴展辞槐，但并不保證附加的

方法能夠被擴展的客戶端和服務(wù)器端所支持。

8.1? GET

GET方法就是以實體方式得到由請求URI所指定資源的信息全封。如果請求URI只是一個

數(shù)據(jù)產(chǎn)生過程马昙，那么最終要在回應(yīng)實體中返回的是由該處理過程的結(jié)果所指向的資源，而不

是返回該處理過程的描述文字刹悴，除非那段文字恰好是處理的輸出给猾。

如果請求消息包含If-Modified-Since標(biāo)題域，GET方法的語法就變成“條件GET”颂跨，即

“（conditional GET）”敢伸。 條件GET方法可以對指定資源進行判斷，如果它在If-Modified-Since

標(biāo)題域（見10.9節(jié)）中的指定日期后發(fā)生了更新恒削，才啟動傳輸池颈，否則不傳輸。這種條件GET

允許被緩存的實體在不必經(jīng)過多次請求或不必要的數(shù)據(jù)傳輸就能進行刷新钓丰，從而有助于降低

網(wǎng)絡(luò)負載躯砰。

8.2? HEAD

HEAD方法與GET幾乎一樣，區(qū)別在于携丁，HEAD方法不讓服務(wù)器在回應(yīng)中返回任何實

體琢歇。對HEAD請求的回應(yīng)部分來說兰怠，它的HTTP標(biāo)題中包含的元信息與通過GET請求所得

到的是相同的。通過使用這種方法李茫，不必傳輸整個實體主體揭保，就可以得到請求URI所指定

資源的元信息。該方法通常用來測試超鏈接的合法性魄宏、可訪問性及最近更新秸侣。

與條件GET不同，不存在所謂的“條件HEAD”宠互，即"conditional HEAD"味榛。即使在HEAD

請求中指定If-Modified-Since標(biāo)題域，它也會被忽略予跌。

8.3? POST

POST方法用來向目的服務(wù)器發(fā)出請求搏色，要求它接受被附在請求后的實體，并把它當(dāng)作

請求隊列（Request-Line）中請求URI所指定資源的附加新子項券册。POST被設(shè)計成用統(tǒng)一的

方法實現(xiàn)下列功能：

o 對現(xiàn)有資源的注釋（Annotation of existing resources）继榆；

o 向電子公告欄、新聞組汁掠，郵件列表或類似討論組發(fā)送消息略吨；

o 提交數(shù)據(jù)塊，如將表格（form [3]）的結(jié)果提交給數(shù)據(jù)處理過程考阱；

o 通過附加操作來擴展數(shù)據(jù)庫翠忠。

POST方法的實際功能由服務(wù)器來決定，而且通常依賴于請求URI乞榨。在POST過程中秽之，

實體是URI的從屬部分，就好象文件從屬于包含它的目錄吃既、新聞組文件從屬于發(fā)出該文件

的新聞組考榨、記錄從屬于其所在的數(shù)據(jù)庫一樣。

成功的POST不需要在原始服務(wù)器創(chuàng)建實體鹦倚，并將其做為資源河质；也不需要為未來的訪問

提供條件。也就是說震叙，POST方法不一定會指向URI指定的資源掀鹅。在這種情況下，200（成

功）或204（無內(nèi)容）都是適當(dāng)?shù)幕貞?yīng)狀態(tài)媒楼，取決于實際回應(yīng)實體中對結(jié)果的描述乐尊。

如果在原始服務(wù)器上創(chuàng)建了資源，回應(yīng)應(yīng)是201（已創(chuàng)建）划址，并包含一個實體

（對"text/html"類型最為適合）扔嵌，該實體中記錄著對新資源請求的狀態(tài)描述限府。

在所有的HTTP/1.0的POST請求中，必須指定合法的內(nèi)容長度（Content-Length）痢缎。如

果HTTP/1.0服務(wù)器在接收到請求消息內(nèi)容時無法確定其長度胁勺，就會返回400（非法請求）

代碼。

應(yīng)用程序不能緩存對POST請求的回應(yīng)牺弄，因為做為應(yīng)用程序來說，它們沒有辦法知道服

務(wù)器在未來的請求中將如何回應(yīng)宜狐。

9.? 狀態(tài)代碼定義（Status Code Definitions）

每個狀態(tài)代碼都將在下面描述势告，包括它們將對應(yīng)哪個方法、以及回應(yīng)中需要的全部元信

息抚恒。

9.1? 消息1xx（Informational 1xx）

該類狀態(tài)代碼用于表示臨時回應(yīng)咱台。臨時回應(yīng)由狀態(tài)行（Status-Line）及可選標(biāo)題組成，

由空行終止俭驮。HTTP/1.0中沒有定義任何1xx的狀態(tài)代碼回溺，所以它們不是對HTTP/1.0請求的

合法回應(yīng)。實際上混萝，它們主要用于實驗用途遗遵，這已經(jīng)超出本文檔的范圍。

9.2? 成功2xx（Successful 2xx）

表示客戶端請求被成功接收逸嘀、理解车要、接受。

200 OK

請求成功崭倘∫硭辏回應(yīng)的信息依賴于請求所使用的方法，如下：

GET 要請求的資源已經(jīng)放在回應(yīng)的實體中了司光。

HEAD 沒有實體主體琅坡，回應(yīng)中只包括標(biāo)題信息。

POST 實體（描述或包含操作的結(jié)果）残家。

201 Created

請求完成榆俺，結(jié)果是創(chuàng)建了新資源。新創(chuàng)建資源的URI可在回應(yīng)的實體中得到坞淮。原

始服務(wù)器應(yīng)在發(fā)出該狀態(tài)代碼前創(chuàng)建該資源谴仙。如果該操作不能立即完成，服務(wù)器必

須在該資源可用時在回應(yīng)主體中給出提示碾盐，否則晃跺，服務(wù)器端應(yīng)回應(yīng)202（可被接受）。

在本文定義的方法毫玖，只有POST可以創(chuàng)建資源掀虎。

202 Accepted

請求被接受凌盯，但處理尚未完成。請求可能不一定會最終完成烹玉，有可能被處理過程隨

時中斷驰怎，在這種情況下，沒有辦法在異步操作中重新發(fā)送狀態(tài)代碼二打。

202回應(yīng)是沒有義務(wù)的县忌，這樣做的目的是允許服務(wù)器不必等到用戶代理和服務(wù)器間

的連接結(jié)束，就可以響應(yīng)其它過程的請求（象每天運行一次的继效，基于批處理的過程）症杏。

在某些回應(yīng)中返回的實體中包括當(dāng)前請求的狀態(tài)指示、狀態(tài)監(jiān)視器指針或用戶對請

求能否實現(xiàn)的評估信息瑞信。

204 No Content

服務(wù)器端已經(jīng)實現(xiàn)了請求厉颤，但是沒有返回新的信息。如果客戶是用戶代理凡简，則勿需

為此更新自身的文檔視圖逼友。該回應(yīng)主要是為了在不影響用戶代理激活文檔視圖的前

提下，進行script語句的輸入及其它操作秤涩。該回應(yīng)還可能包括新的帜乞、以實體標(biāo)題形

式表示的元信息，它可被當(dāng)前用戶代理激活視圖中的文檔所使用筐眷。

9.3? 重定向（Redirection 3xx）

該類狀態(tài)碼表示用戶代理要想完成請求挖函，還需要發(fā)出進一步的操作。這些操作只有

當(dāng)后跟的請求是GET或HEAD時浊竟，才可由用戶代理來實現(xiàn)怨喘，而不用與用戶進行交

互。用戶代理永遠也不要對請求進行5次以上的重定向操作振定，這樣可能導(dǎo)致無限循

環(huán)必怜。

300 Multiple Choices

該狀態(tài)碼不被HTTP/1.0的應(yīng)用程序直接使用，只是做為3xx類型回應(yīng)的缺省解釋后频。

存在多個可用的被請求資源梳庆。

除非是HEAD請求，否則回應(yīng)的實體中必須包括這些資源的字符列表及位置信息卑惜，

由用戶或用戶代理來決定哪個是最適合的膏执。

如果服務(wù)器有首選，它應(yīng)將對應(yīng)的URL信息存放在位置域（Location field）處露久，

用戶代理會根據(jù)此域的值來實現(xiàn)自動的重定向更米。

301 Moved Permanently

請求到的資源都會分配一個永久的URL，這樣就可以在將來通過該URL來訪問此

資源毫痕。有編輯鏈接功能的客戶端會盡可能地根據(jù)服務(wù)器端傳回的新鏈接而自動更新

請求URI征峦。

新的URL必須由回應(yīng)中的位置域指定迟几。除非是HEAD請求，否則回應(yīng)的實體主體

（Entity-Body）必須包括對新URL超鏈接的簡要描述栏笆。

如果用POST方法發(fā)出請求类腮，而接收到301回應(yīng)狀態(tài)碼。在這種情況下蛉加，除非用戶

確認(rèn)蚜枢，否則用戶代理不必自動重定向請求，因為這將導(dǎo)致改變已發(fā)出請求的環(huán)境针饥。

注意：當(dāng)在接收到301狀態(tài)碼后而自動重定向POST請求時厂抽，一些現(xiàn)存的用戶代理

會錯誤地將其改為GET請求。

302 Moved Temporarily

請求到的資源在一個不同的URL處臨時保存打厘。因為重定向有時會被更改修肠，客戶端

應(yīng)繼續(xù)用請求URI來發(fā)出以后的請求贺辰。

新的URL必須由回應(yīng)中的位置域指定户盯。除非是HEAD請求，否則回應(yīng)的實體主體

（Entity-Body）必須包括對新URL超鏈接的簡要描述饲化。

如果用POST方法發(fā)出請求莽鸭，而接收到302回應(yīng)狀態(tài)碼。在這種情況下吃靠，除非用戶

確認(rèn)硫眨，否則用戶代理不必自動重定向請求，因為這將導(dǎo)致改變已發(fā)出請求的環(huán)境巢块。

注意：當(dāng)在接收到302狀態(tài)碼后而自動重定向POST請求時礁阁，一些現(xiàn)存的用戶代理

會錯誤地將其改為GET請求。

304 Not Modified

如果客戶端成功執(zhí)行了條件GET請求族奢，而對應(yīng)文件自If-Modified-Since域所指定

的日期以來就沒有更新過姥闭，服務(wù)器應(yīng)當(dāng)回應(yīng)此狀態(tài)碼，而不是將實體主體發(fā)送給客

戶端越走∨锲罚回應(yīng)標(biāo)題域中只應(yīng)包括一些相關(guān)信息，比如緩存管理器廊敌、與實體最近更新

（entity's Last-Modified）日期無關(guān)的修改铜跑。相關(guān)標(biāo)題域的例子有：日期、服務(wù)器骡澈、

過期時間锅纺。每當(dāng)304回應(yīng)中給出的域值發(fā)生變化，緩存都應(yīng)當(dāng)對緩存的實體進行更

新肋殴。

9.4? 客戶端錯誤（Client Error ）4xx

4xx類的狀態(tài)碼表示客戶端發(fā)生錯誤伞广。如果客戶端在收到4xx代碼時請求還沒有完成拣帽，

它應(yīng)當(dāng)立即終止向服務(wù)器發(fā)送數(shù)據(jù)。除了回應(yīng)HEAD請求外嚼锄，不論錯誤是臨時的還是永久

的减拭，服務(wù)器端都必須在回應(yīng)的實體中包含錯誤狀態(tài)的解釋。這些狀態(tài)碼適用于任何請求方法区丑。

注意：如果客戶端正在發(fā)送數(shù)據(jù)拧粪，服務(wù)器端的TCP實現(xiàn)應(yīng)當(dāng)小心，以確辈捉模客戶端在關(guān)

閉輸入連接之前收到回應(yīng)包可霎。如果客戶端在關(guān)閉后仍舊向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器會給客戶

端發(fā)送一個復(fù)位包宴杀，清空客戶端尚未處理的輸入緩沖區(qū)癣朗，以終止HTTP應(yīng)用程序的讀取、解

釋活動旺罢。

400 非法請求（Bad Request）

如果請求的語法不對旷余，服務(wù)器將無法理解”獯铮客戶端在對該請求做出更改之前正卧，不應(yīng)

再次向服務(wù)器重復(fù)發(fā)送該請求。

401 未授權(quán)（Unauthorized）

請求需要用戶授權(quán)跪解÷酰回應(yīng)中的WWW-Authenticate標(biāo)題域（10.16節(jié)）應(yīng)提示用戶

以授權(quán)方式請求資源〔婕ィ客戶端應(yīng)使用合適的授權(quán)標(biāo)題域（10.2節(jié)）來重復(fù)該請求窘行。如果

請求中已經(jīng)包括了授權(quán)信任信息，那回應(yīng)的401表示此授權(quán)被拒絕图仓。如果用戶代理在多

次嘗試之后罐盔，回應(yīng)一樣還是返回401狀態(tài)代碼，用戶應(yīng)當(dāng)察看一下回應(yīng)的實體透绩，因為在

實體中會包括一些相關(guān)的動態(tài)信息翘骂。HTTP訪問授權(quán)會在11節(jié)中解釋。

403 禁止（Forbidden）

服務(wù)器理解請求帚豪，但是拒絕實現(xiàn)該請求碳竟。授權(quán)對此沒有幫助，客戶端應(yīng)當(dāng)停止重復(fù)

發(fā)送此請求狸臣。如果不是用HEAD請求方法莹桅，而且服務(wù)器端愿意公布請求未被實現(xiàn)原因

的前提下，服務(wù)器會將拒絕原因?qū)懺诨貞?yīng)實體中。該狀態(tài)碼一般用于服務(wù)器端不想公布

請求被拒絕的細節(jié)或沒有其它的回應(yīng)可用诈泼。

404 沒有找到（Not Found）

服務(wù)器沒有找到與請求URI相符的資源懂拾。404狀態(tài)碼并不指明狀況是臨時性的還是

永久性的。如果服務(wù)器不希望為客戶端提供這方面的信息铐达，還回應(yīng)403（禁止）狀態(tài)碼岖赋。

9.5? 服務(wù)器錯誤（Server Error ）5xx

回應(yīng)代碼以‘5’開頭的狀態(tài)碼表示服務(wù)器端發(fā)現(xiàn)自己出現(xiàn)錯誤荣茫，不能繼續(xù)執(zhí)行請

求拄轻。如果客戶端在收到5xx狀態(tài)碼時氏涩，請求尚未完成倾芝，它應(yīng)當(dāng)立即停止向服務(wù)器發(fā)送數(shù)

據(jù)。除了回應(yīng)HEAD請求外羊始，服務(wù)器應(yīng)當(dāng)在其回應(yīng)實體中包括對錯誤情況的解釋鞍时、并

指明是臨時性的還永久性的喷面。

這類回應(yīng)代碼沒有標(biāo)題域偏灿，可適用于任何請求方法丹诀。

500 服務(wù)器內(nèi)部錯誤（Internal Server Error）

服務(wù)器碰到了意外情況，使其無法繼續(xù)回應(yīng)請求翁垂。

501 未實現(xiàn)（Not Implemented）

服務(wù)器無法提供對請求中所要求功能的支持铆遭。如果服務(wù)器無法識別請求方法就會回

應(yīng)此狀態(tài)代碼，這意味著不能回應(yīng)請求所要求的任何資源沮峡。

502 非法網(wǎng)關(guān)（Bad Gateway）

充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器從要發(fā)送請求的上游（upstream）服務(wù)器收到非法的回應(yīng)疚脐。

503 服務(wù)不可用（Service Unavailable）

服務(wù)器當(dāng)前無法處理請求亿柑。這一般是由于服務(wù)器臨時性超載或維護引起的邢疙。該狀態(tài)

碼暗示情況是暫時性的，要產(chǎn)生一些延遲望薄。

注意：503狀態(tài)碼并沒有暗示服務(wù)器在超載時一定要返回此狀態(tài)碼疟游。一些服務(wù)器可

能希望在超載時采用簡單處理，即斷掉連接痕支。

10.? 標(biāo)題域定義（Header Field Definitions）

本節(jié)定義了HTTP/1.0標(biāo)題域常用的語法及語義颁虐。無論是發(fā)送方還是接收方，都有

可能做為客戶端或服務(wù)器端卧须，具體角色取決于在此時刻究竟是誰在接收另绩、誰在發(fā)送。

10.1? 允許（Allow）

表示由請求URI所指定的資源支持在Allow實體標(biāo)題域中列出的方法花嘶，目的是讓接收

方更清楚地知道請求此資源的合法方式笋籽。Allow標(biāo)題域不允許在POST方法中使用，如果非

要這么做椭员，將被忽略车海。

Allow = "Allow" ":" 1#method

Example of use:

Allow: GET, HEAD

該域不能防止客戶端嘗試其它方法。但實際上由Allow標(biāo)題域中的值所表示的指示

信息是有用的隘击，應(yīng)當(dāng)被遵守侍芝。實際的Allow方法集在每次向原始服務(wù)器上發(fā)出請求時定

義研铆。

由于用戶代理（user agent）可能出于其它目的與原始服務(wù)器通訊，做為代理（proxy）

來說州叠，即使無法識別請求所指定的所有方法棵红，也不能修改該請求的Allow標(biāo)題域。

Allow標(biāo)題域并不表示服務(wù)器實現(xiàn)了哪些方法咧栗。

10.2? 授權(quán)（Authorization）

通常窄赋，用戶代理在收到401（未授權(quán)）回應(yīng)時，可能（也可能不會）希望服務(wù)器對其授

權(quán)楼熄。如果希望授權(quán)忆绰，用戶代理將在請求中加入授權(quán)請求標(biāo)題（Authorization request-header）

域。授權(quán)域值由信任證書組成可岂，其中有對用戶代理所請求資源領(lǐng)域的授權(quán)信息错敢。

Authorization? = "Authorization" ":" credentials

HTTP訪問授權(quán)在11節(jié)中描述。如果請求中的授權(quán)指定了一個范圍缕粹，那在此范圍的其

它請求也都具有相同的信任關(guān)系稚茅。

對包含授權(quán)信息域的請求來說，其回應(yīng)是不能被緩存的平斩。

10.3? 內(nèi)容編碼（Content-Encoding）

內(nèi)容編碼的實體標(biāo)題域（entity-header）用作介質(zhì)類型（media-type）的修飾符亚享。它指明

要對資源采用的附加內(nèi)容譯碼方式，因而要獲得內(nèi)容類型（Content-Type）標(biāo)題域中提及的

介質(zhì)類型绘面，必須采用與譯碼方式一致的解碼機制欺税。內(nèi)容編碼主要用來記錄文件的壓縮方法。

各種壓縮方法將在后面列出揭璃。

Content-Encoding = "Content-Encoding" ":" content-coding

內(nèi)容譯碼（Content codings）在3.5節(jié)中定義晚凿，例如：

Content-Encoding: x-gzip

內(nèi)容編碼是請求URI指定資源的一個特性，一般來說瘦馍，資源用編碼方式存儲歼秽，只有在

通過解碼變換以后才能使用。

10.4? 內(nèi)容長度（Content-Length）

內(nèi)容長度（Content-Length）實體標(biāo)題域指明了發(fā)送到接收方的實體主體（Entity-Body）

長度情组，用字節(jié)方式存儲的十進制數(shù)字表示燥筷。對于HEAD方法，其尺寸已經(jīng)在前一次GET請

求中發(fā)出了院崇。

Content-Length = "Content-Length" ":" 1*DIGIT

例如：

Content-Length: 3495

不論實體是何種介質(zhì)類型肆氓，應(yīng)用程序都將通過該域來判定將要傳輸?shù)膶嶓w主體尺寸。所

有包括實體主體的HTTP/1.0的請求消息都必須包括合法的內(nèi)容長度值亚脆。

任何0以上（包括0）的值都是合法的內(nèi)容長度值做院。在7.2.2節(jié)描述了當(dāng)內(nèi)容長度值沒

有給出時，如何決定回應(yīng)實體主體長度的方法。

注意：該域的含義與在MIME中定義的有重要區(qū)別键耕。在MIME中寺滚，它是可選域，只

在"message/external-body"內(nèi)容類型中使用屈雄；而在HTTP中村视，在實體被傳輸前，該域就決定

了實體的長度酒奶。

10.5? 內(nèi)容類型（Content-Type）

內(nèi)容類型實體標(biāo)題域指明了發(fā)送給接收方的實體主體長度蚁孔。對于HEAD方法，介質(zhì)類

型已經(jīng)在前一次GET請求中發(fā)出了惋嚎。

Content-Type? = "Content-Type" ":" media-type

介質(zhì)類型在3.6節(jié)中定義杠氢，如下例：

Content-Type: text/html

更多關(guān)于介質(zhì)類型的討論在7.2.1節(jié)。

10.6? 日期（Date）

日期普通標(biāo)題（Date general-header）域表示消息產(chǎn)生的時間另伍，其語法與RFC822中定義

的orig-date是一樣的鼻百。該域值是HTTP型日期，在3.3節(jié)中描述摆尝。

Date = "Date" ":" HTTP-date

例如：

Date: Tue, 15 Nov 1994 08:12:31 GMT

如果直接通過用戶代理（如請求）或原始服務(wù)器（如回應(yīng)）的連接接收到消息温艇，日期可

以認(rèn)為是接收端的當(dāng)前時間。然而堕汞，對于原始服務(wù)器來說勺爱，時間對其回應(yīng)緩存的處理非常重

要，所以讯检，原始服務(wù)器的回應(yīng)總是包括日期標(biāo)題琐鲁。客戶端只有在發(fā)送帶實體的消息時视哑，才可

向服務(wù)器發(fā)送日期標(biāo)題域绣否，比如POST請求誊涯。如果接收到的消息被接收方或網(wǎng)關(guān)通過有日期

要求的協(xié)議緩存起來時挡毅，該消息即使沒有日期標(biāo)題域，接收方也會為其分配一個暴构。

理論上跪呈，日期應(yīng)當(dāng)在實體產(chǎn)生時生成，而實際上取逾，日期可能在消息產(chǎn)生過程的任意時間

生成耗绿，而不會造成任何不利的影響。

注意：早期版本錯誤地將此域值定義為實體主體封裝時的日期砾隅。這已經(jīng)被實際應(yīng)用所更

正误阻。

10.7? 過期（Expires）

過期實體標(biāo)題域中的日期/時間值指定了實體過期的時間。這為信息提供方提供了使信

息失效的手段。當(dāng)超過此期限時究反，應(yīng)用程序不應(yīng)再對此實體進行緩存了寻定。過期并不意味著原

始資源會在此期限后發(fā)生改變或停止存在。在實際應(yīng)用中精耐，信息提供者通過檢查過期標(biāo)題域

中所指定的時間狼速，從而獲知或預(yù)測資源將會發(fā)生改變的確切日期。該格式用的是絕對日期時

間（3.2節(jié)）卦停。

Expires = "Expires" ":" HTTP-date

例如：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

如果給定日期比日期標(biāo)題中的要早（或相同）向胡，接收方不應(yīng)緩存附加的實體。如果資源

是動態(tài)自然生成的惊完，象有些大量數(shù)據(jù)的處理僵芹，資源的實體應(yīng)當(dāng)被加上一個適當(dāng)?shù)倪^期時間值。

過期域并不能強制用戶代理對其進行刷新或重新載入資源小槐，它只用于緩存機制淮捆。當(dāng)對已

初始化過的資源發(fā)出新請求時，該機制才檢查該資源的過期狀態(tài)本股。

用戶代理通常都有歷史記錄機制攀痊，如“后退”按鈕和歷史記錄列表。該種機制可以用來

重新顯示某次對話（session）之前已經(jīng)獲取的實體信息拄显。在缺省狀態(tài)下苟径，過期域不對歷史機

制使用。除非用戶在配置用戶代理時指定了對歷史文件進行過期刷新躬审，否則棘街，只要實體還保

存著，歷史機制就能顯示它承边，不論該實體是否已經(jīng)過期遭殉。

注意：應(yīng)用程序應(yīng)兼容對過期標(biāo)題非法或錯誤的實現(xiàn)，如碰到0值或非法的日期格式博助，

應(yīng)用程序應(yīng)將其視為“立即過期（expires immediately）”险污。雖然這些值不符合HTTP/1.0，對

于一個健壯的應(yīng)用來說富岳，還是必要的蛔糯。

10.8? 來自（From）

From請求標(biāo)題域，如果給出來窖式，則應(yīng)包括一個使用此用戶代理的人類用戶的Internet

e-mail地址蚁飒。該地址應(yīng)當(dāng)能被系統(tǒng)識別，就象RFC822[7]（已經(jīng)更新為RFC1123[6]）中的郵

箱定義一樣萝喘。

From = "From" ":" mailbox

例如：

From: webmaster@w3.org

該標(biāo)題域可能用來做為登錄目的使用淮逻，以確定對某資源的請求是否合法琼懊。它不應(yīng)用于不

安全的訪問保護。該域的解釋是爬早，請求已按請求人指定的行為方式完成肩碟，而該請求人將為此

種方式負責(zé)。特殊情況下凸椿，機器人（robot）代理也應(yīng)包括此標(biāo)題域削祈，域中注明是誰運行它

的，這樣脑漫，當(dāng)接收端發(fā)生任何問題時髓抑，都可以同這個人取得聯(lián)系。

該域中的Internet e-mail地址可以與處理該請求的Internet主機分離优幸。例如吨拍，當(dāng)請求通過

代理（proxy）時，應(yīng)使用原始的傳輸?shù)刂贰?/p>

注意：客戶端在沒有得到用戶批準(zhǔn)時网杆，不應(yīng)發(fā)送From標(biāo)題域羹饰，因為這樣做可能會產(chǎn)生

用戶隱私及網(wǎng)站安全方面的問題。強烈建議在請求之前提供手段以禁止（disable）碳却、允許

（enable）队秩、修改（modify）該域的值。

10.9? 從何時更改（If-Modified-Since）

If-Modified-Since請求標(biāo)題域和GET方法一起使用昼浦，用于處理下面情況：當(dāng)在該域指定

的日期以來馍资，請求資源沒有發(fā)生任何變更。這時关噪，服務(wù)器將不會下傳該資源的拷貝鸟蟹，即，回

應(yīng)不帶任何實體主體使兔，只是304狀態(tài)碼（未修改）建钥。

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

例如：

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

條件GET方法可以請求服務(wù)端將在If-Modified-Since標(biāo)題域中的指定日期后發(fā)生變更

的指定資源下傳，也就是說虐沥，如果資源沒發(fā)生變化熊经，就不下傳了。其算法如下：

a) 如果請求的回應(yīng)狀態(tài)不是200（成功）碼或它傳過來的If-Modified-Since中的

日期不合法置蜀，此時按照普通GET來回應(yīng)奈搜。如果日期比服務(wù)器的當(dāng)前時間還要

晚，則是非法時間盯荤。

b) 如果資源在If-Modified-Since日期以后有變化，回應(yīng)也和普通GET一樣

c) 如果資源在If-Modified-Since日期以后沒變化焕盟，服務(wù)器端將回應(yīng)304（未修改）秋秤。

注：該日期應(yīng)是合法的宏粤。

這樣做的目的是為了以最小的代價，對被緩存信息進行有效更新灼卢。

10.10? 最近更改（Last-Modified）

Last-Modified實體標(biāo)題域表示由發(fā)送方設(shè)定的資源最近修改日期及時間绍哎。該域的精確定

義在于接收方如何去解釋它：如果接收方已有此資源的拷貝，但此拷貝比Last-Modified域

所指定的要舊鞋真，該拷貝就是過期的崇堰。

Last-Modified? = "Last-Modified" ":" HTTP-date

例如：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

該標(biāo)題域的精確含義取決于發(fā)送方的執(zhí)行方式及原始資源的自然狀態(tài)。對于文件來說涩咖，

可能是它在文件系統(tǒng)的last-modified時間海诲。對于包含多個組成部分的實體來說，可能是組成

部分中最新的last-modify時間檩互。對數(shù)據(jù)庫網(wǎng)關(guān)來說特幔，可能是記錄的last-update時間戳。對于

虛（virtual）對象來說闸昨，可能是內(nèi)部狀態(tài)的最近改變時間蚯斯。

原始服務(wù)器不應(yīng)發(fā)送比服務(wù)器消息產(chǎn)生時間更晚的Last-Modified日期，因為該消息會

導(dǎo)致服務(wù)器在未來的某個時間內(nèi)饵较，用消息原始的日期對該域值進行再次更新拍嵌。

10.11? 位置（Location）

Location回應(yīng)標(biāo)題域定義了由請求URI指定的資源的位置。對于3xx（重定向）回應(yīng)循诉，

位置域必須能幫助服務(wù)器找到相應(yīng)的URL撰茎，以實現(xiàn)對資源的重定向。只允許用絕對URL打洼。

Location? ? ? = "Location" ":" absoluteURI

例如：

Location: http://www.w3.org/hypertext/WWW/NewLocation.html

10.12? 注解（Pragma）

Prama普通標(biāo)題域包括一些可能對請求/回應(yīng)鏈中的任一接收方有用的特殊指示信息龄糊。

從協(xié)議角度看，所有的注解指示了一些特定的可選行為募疮，事實上炫惩，一些系統(tǒng)可能會要求行為

與指示一致。

Pragma = "Pragma" ":" 1#pragma-directive

pragma-directive = "no-cache" | extension-pragma

extension-pragma = token [ "=" word ]

當(dāng)"no-cache"出現(xiàn)在請求消息中時阿浓，應(yīng)用程序應(yīng)當(dāng)向原始服務(wù)器推送此請求他嚷，即使它已

經(jīng)在上次請求時已經(jīng)緩存了一份拷貝。這樣將保證客戶端能接收到最權(quán)威的回應(yīng)芭毙。它也用來

在客戶端發(fā)現(xiàn)其緩存中拷貝不可用或過期時筋蓖，對拷貝進行強制刷新。

不管注解（Pragma）指示信息對代理（proxy）及網(wǎng)關(guān)（gateway）應(yīng)用程序如何重要退敦，

它必須能穿越這些應(yīng)用粘咖，因為該信息可能對請求/回應(yīng)鏈上的其它接收方有用。實際上侈百，如

果注解與某個接收方無關(guān)瓮下，它應(yīng)當(dāng)被該接收方忽略翰铡。

10.13 提交方（Referer）

提交方請求標(biāo)題域是出于服務(wù)器端利益方面的考慮，允許客戶端指明該鏈接的出處讽坏，即

該指向資源地址的請求URI是從哪里獲得的锭魔。這樣，服務(wù)器將產(chǎn)生一個備份鏈接（back-links）

列表路呜，用于維護受歡迎的資源迷捧、登錄、緩存優(yōu)化等活動胀葱。

Referer = "Referer" ":" ( absoluteURI | relativeURI )

例子：

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

如果只給了部分URI漠秋，應(yīng)當(dāng)參照請求URI來解釋它。URI不能包括段（fragment）巡社。

注意：因為鏈接的原代碼可能暴露一些隱私信息膛堤，因此強烈建議由用戶來決定是否發(fā)送

提交人域。例如晌该，瀏覽器客戶端有個選項可以用來進行離線瀏覽肥荔，可以使能或禁止提交人或

表單信息的發(fā)送。

10.14? 服務(wù)器（Server）

服務(wù)器回應(yīng)標(biāo)題域包含由原始服務(wù)器用來處理請求的軟件信息朝群。該域可包含多個產(chǎn)品標(biāo)

識（3.7節(jié)）及注釋以標(biāo)識服務(wù)器及重要的子產(chǎn)品燕耿。按照習(xí)慣，產(chǎn)品標(biāo)識將按其應(yīng)用的重要

順序排列姜胖。

Server? ? ? ? = "Server" ":" 1*( product | comment )

例如：

Server: CERN/3.0 libwww/2.17

如果回應(yīng)要通過代理來推送誉帅，代理應(yīng)用程序不應(yīng)將它自己的數(shù)據(jù)加入產(chǎn)品列表。

注意：一些指定服務(wù)器軟件的版本有啟示作用右莱，因為這些版本的軟件存在一些安全漏洞蚜锨，

將使服務(wù)器更易受到攻擊。提倡服務(wù)器軟件在實現(xiàn)時慢蜓，將此域變成可以進行配置的選項亚再。

注意：有些服務(wù)器不遵守服務(wù)器域產(chǎn)品標(biāo)識的語法約束。

10.15? 用戶代理（User-Agent）

用戶代理請求標(biāo)題域包含用戶原始請求的信息晨抡，這可用于統(tǒng)計方面的用途氛悬。通過跟蹤協(xié)

議沖突、自動識別用戶代理以避免特殊用戶代理的局限性耘柱，從而做到更好的回應(yīng)如捅。雖然沒有

規(guī)定，用戶代理應(yīng)當(dāng)在請求中包括此域调煎。該域可包含多個產(chǎn)品標(biāo)識（3.7節(jié)）及注釋以標(biāo)識

該代理及其重要的子產(chǎn)品镜遣。按照習(xí)慣，產(chǎn)品標(biāo)識將按子產(chǎn)品對應(yīng)用的重要性順序排列汛蝙。

User-Agent? ? = "User-Agent" ":" 1*( product | comment )

例如：

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

注意：現(xiàn)存有些代理應(yīng)用將它們的產(chǎn)品信息回到了用戶代理域中烈涮，這種方法不值得提倡朴肺，

因為這樣做會使機器在解釋這些信息時產(chǎn)生混淆窖剑。

注意：現(xiàn)在有些客戶端不遵守用戶代理域中產(chǎn)品標(biāo)識的語法約束坚洽。

10.16? WWW-授權(quán)（WWW-Authenticate）

WWW-授權(quán)回應(yīng)標(biāo)題域必須被包括在401（未授權(quán)）回應(yīng)消息中。該域值由一個以上的

challenge組成西土，這些challenge可用于指出請求URI的授權(quán)方案及參數(shù)讶舰。

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

HTTP訪問授權(quán)處理在11節(jié)中描述。用戶代理在解析WWW-授權(quán)域值時要特別注意看

看它是否包含一個以上的待解決問題（challenge）或是否提供了一個以上的WWW-授權(quán)標(biāo)

題域需了，因為待解決問題（challenge）的內(nèi)容中可能包含用逗號分隔的授權(quán)參數(shù)列表跳昼。

11.? 訪問鑒別（Access Authentication）

HTTP提供了一個簡單的質(zhì)詢回應(yīng)（challenge-response）鑒別機制，可用于服務(wù)器通過

客戶端提供的授權(quán)信息來對其進行身份鑒別肋乍。授權(quán)方案用可擴展的鹅颊、大小寫敏感的符號來標(biāo)

識，后跟獲取證明所需要的以逗號分隔的‘屬性－值’對墓造。

auth-scheme? ? = token

auth-param? ? = token "=" quoted-string

原始服務(wù)器用401（未授權(quán)）回應(yīng)消息來質(zhì)詢用戶代理的授權(quán)堪伍。該回應(yīng)必須包括WWW-

授權(quán)標(biāo)題域，而該WWW-授權(quán)標(biāo)題域包括一個以上用于請求資源認(rèn)證的參數(shù)（challenge）茄螃。

challenge = auth-scheme 1*SP realm *( "," auth-param )

realm = "realm" "=" realm-value

realm-value = quoted-string

凡涉及到參數(shù)（challenge）處理的授權(quán)方案都有realm屬性（大小寫敏感）菜秦。與標(biāo)準(zhǔn)URL

（相對于被訪問服務(wù)器root）聯(lián)合使用的realm值（也是大小寫敏感）用來定義保護區(qū)域绪爸。

Realm使得服務(wù)器上的被保護資源被放在特殊的保護分區(qū)內(nèi)，這些區(qū)域都有各自的授權(quán)方案

和（或）授權(quán)數(shù)據(jù)庫尸闸。Relm值是個字符串，通常由原始服務(wù)器來分配孕锄，對于授權(quán)方案來說吮廉，

可能存在些附加的語法處理問題。

通常畸肆，用戶代理在收到401（未授權(quán)）回應(yīng)時宦芦，可能（也可能不會）希望服務(wù)器對其授

權(quán)。如果希望授權(quán)恼除，用戶代理將在請求中加入授權(quán)請求標(biāo)題（Authorization request-header）

域踪旷。授權(quán)域值由信任證書組成，其中有對用戶代理所請求資源領(lǐng)域的授權(quán)信息豁辉。

credentials? ? = basic-credentials

| ( auth-scheme #auth-param )

可由用戶代理通過信任方式來訪問的區(qū)域由保護區(qū)域決定令野。如果早先的請求已經(jīng)通過認(rèn)

證，在由授權(quán)方案徽级，參數(shù)和（或）用戶選擇等所指定的時間間隔內(nèi)气破，其它的請求可通過相同

的信任來訪問該保護區(qū)域。

除非由授權(quán)另行指定餐抢，否則單個保護區(qū)域的范圍不能擴展到服務(wù)器之外现使。

如果服務(wù)器不希望通過請求來接受信任低匙，它應(yīng)當(dāng)返回403（禁止）回應(yīng)。

HTTP協(xié)議的訪問授權(quán)不限于這種簡單的質(zhì)詢回應(yīng)（challenge-response）機制碳锈，還可以

使用其它的方法顽冶，比如傳輸級加密或消息封裝及通過附加標(biāo)題域來指定授權(quán)信息等等。但是售碳，

這些方法不在本文檔的討論范圍强重。

代理必須完全透明地處理用戶授權(quán)，也就是說贸人，它們必須在不做任何改動的前提下將

WWW-授權(quán)及授權(quán)標(biāo)題向前推送间景，也不可以對包含授權(quán)的回應(yīng)進行緩存。HTTP/1.0不為客

戶端提供通過代理方式授權(quán)的方法艺智。

11.1? 基本授權(quán)方案（Basic Authentication Scheme）

用戶代理必須對于每個領(lǐng)域（realm）通過用戶標(biāo)識（user-ID）及口令來對自身進行授

權(quán)倘要，這是基本授權(quán)方案的工作模式。Realm值應(yīng)當(dāng)被看作不透明的字符串十拣，該值將用于同服

務(wù)器端其它的realm值相比較封拧。只有用戶標(biāo)識及口令通過受保護資源的認(rèn)證，服務(wù)器才會給

請求授權(quán)父晶。授權(quán)參數(shù)沒有可選項哮缺。

在接收到對受保護區(qū)域的未經(jīng)認(rèn)證的資源請求時，服務(wù)器應(yīng)當(dāng)回應(yīng)一個質(zhì)詢

（challenge）甲喝，如下：

WWW-Authenticate: Basic realm="WallyWorld"

"WallyWorld"是由服務(wù)器分配的字符串尝苇，用于對請求URI所指定的受保護資源進行標(biāo)

識。

為了接收授權(quán)埠胖，客戶端需要在基于64位（base64 [5]）的證書中發(fā)送用戶標(biāo)識及口令糠溜，

中間用冒號':'分隔。

basic-credentials = "Basic" SP basic-cookie

basic-cookie? ? ? =

except not limited to 76 char/line>

userid-password? = [ token ] ":" *TEXT

如果用戶代理希望發(fā)送用戶標(biāo)識"Aladdin"和口令“open sesame”直撤，應(yīng)當(dāng)遵循下面的標(biāo)題

域形式：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basic授權(quán)方案是對HTTP服務(wù)器資源的非授權(quán)訪問進行過濾的非安全方法非竿。它基于假

定客戶端與服務(wù)器端的連接是安全的，為什么說是假定呢谋竖，因為在實際的開放性網(wǎng)絡(luò)中红柱，使

用basic授權(quán)方案往往存在許多不安全的地方。盡管如此蓖乘，客戶端仍然需要實現(xiàn)此方案锤悄，以

與采用此種方案的服務(wù)器進行通訊。

12.? 安全考慮（Security Considerations）

本節(jié)的描述對下面各角色有關(guān)：信息應(yīng)用開發(fā)者嘉抒、信息提供者零聚、HTTP/1.0中受安全性

限制的用戶。本節(jié)僅是討論安全問題，并對減少隱患提出了建議隶症，但是并不提供對問題的最

終解決辦法政模。

12.1? 客戶授權(quán)（Authentication of Clients）

正如11.1節(jié)中所述，基本授權(quán)（Basic authentication）方案不是安全的用戶授權(quán)方案蚂会，

也不能用它來防止實體主體源碼以文本方式在物理網(wǎng)絡(luò)中傳輸淋样。HTTP/1.0并不反對在目前

日益突出的安全問題面前采用其它的授權(quán)方式及加密機制。

12.2? 安全方法（Safe Methods）

客戶端軟件開發(fā)者應(yīng)當(dāng)注意颂龙，客戶端軟件代表用戶在Internet上與其它方面交互习蓬，并應(yīng)

注意避免讓用戶知道其間發(fā)生的具體動作纽什，這些動作可能會暴露對交互各方有重要意義的信

息措嵌。

特別情況下，按協(xié)定來看芦缰，GET和HEAD方法應(yīng)被視作是安全的企巢，同重新獲得數(shù)據(jù)應(yīng)

當(dāng)沒有什么不同。這就允許用戶代理采用其它方法让蕾，如POST浪规，在某種情況下，可能存在這

樣一種情況探孝，即請求中包含不安全的行為笋婿。

通常，服務(wù)器端在執(zhí)行過GET請求之后顿颅，其結(jié)果之類的副產(chǎn)品還殘留在服務(wù)器上缸濒；實

際上，一些動態(tài)資源需要這種特性來實現(xiàn)粱腻。這里的重要區(qū)別在于用戶沒有請求這些副產(chǎn)品庇配，

因而也不應(yīng)當(dāng)對這類請求進行解釋。

12.3? 服務(wù)器日志信息的弊端（Abuse of Server Log

Information）

服務(wù)器為保存與用戶請求相關(guān)的個人數(shù)據(jù)绍些，如閱讀方式或感興趣的主題等提供了空間捞慌。

這些存儲信息顯然是受某些國家法律保護的，所以對此類數(shù)據(jù)的處理應(yīng)當(dāng)小心柬批。用HTTP

協(xié)議提供數(shù)據(jù)的一方應(yīng)當(dāng)負責(zé)保證這些信息在未得各方許可之前不會散布出去啸澡。

12.4? 敏感信息傳輸（Transfer of Sensitive Information）

與其它協(xié)議一樣，HTTP協(xié)議不能調(diào)整傳輸數(shù)據(jù)的內(nèi)容氮帐，也不存在未卜先知的方法嗅虏，通

過給定請求的上下文信息片段就能推測出信息的敏感程度。因而揪漩，應(yīng)用程序應(yīng)當(dāng)盡可能像信

息提供方一樣旋恼，為該信息提供更多的控制。在此，有三個標(biāo)題域值得一提：服務(wù)端（Server）冰更、

提交方（Referer）和來自（From）产徊。

一些指定服務(wù)器軟件的版本有啟示作用，因為這些版本的軟件存在一些安全漏洞蜀细，將使

服務(wù)器更易受到攻擊舟铜。提倡服務(wù)器軟件在實現(xiàn)時，將Server標(biāo)題域變成可以進行配置的選

項奠衔。

提交方（Referer）標(biāo)題域允許閱讀方式（reading patterns）被暴露谆刨，并可導(dǎo)出反向鏈接。

雖然該域很有用归斤，但是如果包含在此域的用戶信息如果沒有被分開痊夭，則它的作用很可能被濫

用。另外脏里，即使此域中用戶信息被清除她我，從該域的其它信息仍可推測出其私有文件的URI，

這可能是該信息發(fā)布者所不想看到的迫横。

來自（From）標(biāo)題域可能包括一些與用戶私人隱私及站點安全相關(guān)的信息番舆，因而，在

發(fā)送數(shù)據(jù)前矾踱，應(yīng)當(dāng)允許用戶使用一些設(shè)定手段恨狈，如禁止（disable）、允許（enable）呛讲、及修改

（modify）禾怠，對此域信息進行配置。用戶應(yīng)當(dāng)能夠根據(jù)他們的選擇或使用應(yīng)用程序提供的缺

省配置來設(shè)定此域的內(nèi)容圣蝎。

我們建議刃宵，但不做要求：為用戶提供方便的界面來允許（enable）或禁止（disable）發(fā)

送From域或Referer域的信息。

12.5? 基于文件及路徑名的攻擊（Attacks Based On File and

Path Names）

HTTP原始服務(wù)器的實現(xiàn)應(yīng)當(dāng)注意徘公，要對以服務(wù)器管理員名義發(fā)出的牲证，對某個文件的

HTTP請求進行限制。如果HTTP服務(wù)器直接將HTTP URI發(fā)送給系統(tǒng)調(diào)用关面，服務(wù)器要特別

注意坦袍，當(dāng)某個請求文件不是發(fā)往HTTP客戶端時，要予以拒絕服務(wù)等太。例如捂齐，在Unix、Microsoft

Windows以及其它的操作系統(tǒng)使用".."做為上級目錄名缩抡。在這樣的系統(tǒng)下奠宜，HTTP服務(wù)器端

必須禁止通過使用這種結(jié)構(gòu)的請求URI來訪問HTTP服務(wù)器其它范圍的資源。同樣，服務(wù)

器端內(nèi)部使用的一些文件压真，包括訪問控制文件娩嚼，配置文件、script代碼等滴肿，也要受到特別保

護岳悟，以避免被非法請求獲取，導(dǎo)致系統(tǒng)敏感信息暴露泼差。實驗證明贵少，哪怕是最小的bug，也可

能導(dǎo)致嚴(yán)重的安全問題堆缘。

13.? 感謝（Acknowledgments）

本文檔著重論述補充反饋方式（augmented BNF）及由David H. Crocker在RFC822[7]

中定義的一般結(jié)構(gòu)滔灶。同樣，它使用了許多由Nathaniel Borenstein和Ned Freed為MIME [5]

做的許多定義套啤。我們希望通過它們來減少對HTTP/1.0及mail消息格式之間關(guān)系的混淆宽气。

HTTP協(xié)議在過去四年中發(fā)展很快，它得益于龐大而活躍的開發(fā)團體――是他們潜沦，這些

參與WWW討論郵件列表的人們，造就了HTTP在全球范圍內(nèi)的成功绪氛。Marc Andreessen唆鸡，

Robert Cailliau， Daniel W. Connolly枣察，Bob Denny争占，Jean-Francois Groff， Phillip M.

Hallam-Baker序目， Hakon W. Lie臂痕， Ari Luotonen，Rob McCool猿涨， Lou? Montulli握童， Dave Raggett，

Tony Sanders叛赚，和Marc VanHeyningen澡绩，他們?yōu)楸疚臋n早期版本投入了巨大精力。Paul Hoffman

提供了關(guān)于信息狀態(tài)方面的信息俺附，以及附錄C肥卡、D的內(nèi)容。

該文檔從HTTP-WG成員的評注中得益非淺事镣。以下是對本規(guī)范做出貢獻的人們：

Gary Adams Harald Tveit Alvestrand

Keith Ball Brian Behlendorf

Paul Burchard Maurizio Codogno

Mike Cowlishaw Roman Czyborra

Michael A. Dolan John Franks

Jim Gettys Marc Hedlund

Koen Holtman Alex Hopmann

Bob Jernigan Shel Kaphan

Martijn Koster Dave Kristol

Daniel LaLiberte Paul Leach

Albert Lunde John C. Mallery

Larry Masinter Mitra

Jeffrey Mogul Gavin Nicol

Bill Perry Jeffrey Perry

Owen Rees Luigi Rizzo

David Robinson Marc Salomon

Rich Salz Jim Seidman

Chuck Shotton Eric W. Sink

Simon E. Spero Robert S. Thau

Francois Yergeau Mary Ellen Zurko

Jean-Philippe Martin-Flatin

14. 參考書目（References）

[1]? Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,

Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A

Distributed Document Search and Retrieval Protocol", RFC 1436,

University of Minnesota, March 1993.

[2]? Berners-Lee, T., "Universal Resource Identifiers in WWW: A

Unifying Syntax for the Expression of Names and Addresses of

Objects on the Network as used in the World-Wide Web",

RFC 1630, CERN, June 1994.

[3]? Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -

2.0", RFC 1866, MIT/W3C, November 1995.

[4]? Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform

Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,

University of Minnesota, December 1994.

[5]? Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail

Extensions) Part One: Mechanisms for Specifying and Describing

the Format of Internet Message Bodies", RFC 1521, Bellcore,

Innosoft, September 1993.

[6]? Braden, R., "Requirements for Internet hosts - Application and

Support", STD 3, RFC 1123, IETF, October 1989.

[7]? Crocker, D., "Standard for the Format of ARPA Internet Text

Messages", STD 11, RFC 822, UDEL, August 1982.

[8]? F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,

J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype

Functional Specification." (v1.5), Thinking Machines

Corporation, April 1990.

[9]? Fielding, R., "Relative Uniform Resource Locators", RFC 1808,

UC Irvine, June 1995.

[10] Horton, M., and R. Adams, "Standard for interchange of USENET

Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell

Laboratories, Center for Seismic Studies, December 1987.

[11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:

A Proposed Standard for the Stream-Based Transmission of News",

RFC 977, UC San Diego, UC Berkeley, February 1986.

[12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,

USC/ISI, August 1982.

[13] Postel, J., "Media Type Registration Procedure." RFC 1590,

USC/ISI, March 1994.

[14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",

STD 9, RFC 959, USC/ISI, October 1985.

[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC

1700, USC/ISI, October 1994.

[16] Sollins, K., and L. Masinter, "Functional Requirements for

Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,

December 1994.

[17] US-ASCII. Coded Character Set - 7-Bit American Standard Code

for Information Interchange. Standard ANSI X3.4-1986, ANSI,

1986.

[18] ISO-8859. International Standard -- Information Processing --

8-bit Single-Byte Coded Graphic Character Sets --

Part 1: Latin alphabet No. 1, ISO 8859-1:1987.

Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.

Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.

Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.

Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.

Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.

Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.

Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.

Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

15.? 作者地址（Authors' Addresses）

Tim Berners-Lee

Director, W3 Consortium

MIT Laboratory for Computer Science

545 Technology Square

Cambridge, MA 02139, U.S.A.

Fax: +1 (617) 258 8682

EMail: timbl@w3.org

Roy T. Fielding

Department of Information and Computer Science

University of California

Irvine, CA 92717-3425, U.S.A.

Fax: +1 (714) 824-4056

EMail: fielding@ics.uci.edu

Henrik Frystyk Nielsen

W3 Consortium

MIT Laboratory for Computer Science

545 Technology Square

Cambridge, MA 02139, U.S.A.

Fax: +1 (617) 258 8682

EMail: frystyk@w3.org

附錄（Appendices）

這些信息出現(xiàn)在附錄中僅有一個理由步鉴，即他們沒有成為HTTP/1.0規(guī)范的組成部分。

A.? Internet介質(zhì)類型消息/http（Internet Media Type

message/http）

做為HTTP/1.0協(xié)議的補充，該文檔做為Internet介質(zhì)類型"message/http"的規(guī)范氛琢。下面

內(nèi)容被登記在IANA[13]中只嚣。

介質(zhì)類型名（Media Type name）： message

介質(zhì)子類型名（Media subtype name）： http

請求參數(shù)（Required parameters）： none

可選參數(shù)項（Optional parameters）： version, msgtype

版本（version）：附加消息的HTTP版本號，比如“1.0”艺沼。如果沒有給出册舞，版

本可以從其主體的第一行中得到。

消息類型（msgtype）：消息類型――請求（request）或回應(yīng)（response）障般。如果

沒有給出调鲸，版本可以從其主體的第一行中得到。

編碼考慮（Encoding considerations）：只允許用"7bit", "8bit",或"binary" 挽荡。

安全考慮（Security considerations）： none

B.? 容錯應(yīng)用（Tolerant Applications）

雖然此文檔指明了產(chǎn)生HTTP/1.0消息的必要條件藐石，并非所有的應(yīng)用程序都校正他們的

實現(xiàn)。因此定拟，我們建議應(yīng)用程序增強其容錯能力于微，以便在岐義仍可被明確解釋時，還能保證

正常運行青自。

客戶端解析狀態(tài)行（Status-Line）及服務(wù)器解析請求行（Request-Line）時株依，應(yīng)當(dāng)做到容

錯。特別是延窜，即使只需要一個SP分隔的情況下恋腕，它們也可接受以任何數(shù)量的SP或HT字

符分隔的域。

HTTP標(biāo)題域的行終止符是順序字符CRLF逆瑞。而我們建議應(yīng)用程序在解析這類標(biāo)題時荠藤，

也應(yīng)識別單個LF（沒有前面的CR）做為終止符情況。

C.? 與MIME的關(guān)系（Relationship to MIME）

HTTP/1.0使用了許多為Internet Mail（RFC822[7]）及多用途Internet郵件擴展

（Multipurpose Internet Mail Extensions）MIME[5]定義的結(jié)構(gòu)获高，以允許實體通過一種開放的

可擴展的機制進行傳輸哈肖。實際上，HTTP中有些特性與RFC1521中討論的郵件不同念秧，這些

區(qū)別被用來優(yōu)化二進制傳輸?shù)男阅苡倬o介質(zhì)類型的使用提供了更大的自由度，使日期比較變

得更加容易出爹，當(dāng)然庄吼，這也是為了兼容早期的一些HTTP服務(wù)器及客戶端的應(yīng)用。

在寫作本文時严就，據(jù)說RFC1521將被修訂总寻。修訂版本將會包括一些出現(xiàn)在HTTP/1.0中的

已有的應(yīng)用，但這些應(yīng)用在目前的RFC1521中尚未包括梢为。

該附錄描述了HTTP與RFC1521中的不同之處渐行。代理和網(wǎng)關(guān)在限制MIME環(huán)境時轰坊，應(yīng)

當(dāng)注意到這些區(qū)別，并在必須時提供相應(yīng)的轉(zhuǎn)換支持祟印。從MIME到HTTP環(huán)境的代理和網(wǎng)

關(guān)也要注意這些區(qū)別肴沫，因為一些轉(zhuǎn)換可能是必須的。

C.1? 轉(zhuǎn)換為規(guī)范形式（Conversion to Canonical Form）

RFC1521要求Internet郵件實體在被傳輸前轉(zhuǎn)換成規(guī)范形式蕴忆，正如RFC1521[5]附錄C

中所描述的那樣颤芬。本文檔中3.6.1節(jié)中描述了HTTP在傳輸時允許的“text”介質(zhì)類型的子類

型的具體形式。

RFC1521要求"text"的內(nèi)容類型（Content-Type）必須用CRLF作為行中斷符套鹅，禁止單獨

使用CR或LF站蝠。HTTP允許在HTTP傳輸時使用CRLF、單獨的CR或LF做為行中斷符卓鹿。

只要有可能菱魔，HTTP環(huán)境或RFC1521環(huán)境下的代理或網(wǎng)關(guān)應(yīng)當(dāng)將本文檔3.6.1節(jié)中描述

的文本介質(zhì)類型中的所有行中斷符都轉(zhuǎn)換成CRLF。注意吟孙，由于存在著內(nèi)容編碼

（Content-Encoding）問題澜倦，以及HTTP允許使用多字符集，而其中的某些字符集不用字節(jié)

13和10做為CR和LF杰妓，這樣就使實際的處理更加復(fù)雜藻治。

C.2? 日期格式轉(zhuǎn)換（Conversion of Date Formats）

HTTP/1.0使用受限制的日期格式集（3.3節(jié)）以簡化日期比較的處理。其它協(xié)議的代理

和網(wǎng)關(guān)應(yīng)當(dāng)保證消息中的任何日期標(biāo)題域與HTTP/1.0格式一致稚失，否則栋艳，要對其進行改寫。

C.3? 內(nèi)容編碼介紹（Introduction of Content-Encoding）

RFC1521不包括殊如HTTP/1.0中內(nèi)容編碼標(biāo)題域之類的概念句各。由于內(nèi)容類型域是介質(zhì)

類型的修飾，因而從HTTP到MIME兼容協(xié)議中的代理和網(wǎng)關(guān)必須在將消息向前推送之前晴叨，

更改內(nèi)容類型標(biāo)題域（Content-Type）的值或者對實體主體（Entity-Body）進行解碼（有些

Internet mail內(nèi)容類型的實驗性應(yīng)用采用介質(zhì)類型參數(shù)為";conversions="來

替代內(nèi)容解碼凿宾，而事實上，該參數(shù)并非RFC1521的組成部分）兼蕊。

C.4? 無內(nèi)容傳輸編碼（No Content-Transfer-Encoding）

HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域初厚。與MIME協(xié)議兼容的

代理和網(wǎng)關(guān)在向HTTP客戶端傳遞回應(yīng)消息前都必須清除任何無標(biāo)識的CTE編碼

（"quoted-printable"或"base64"）。

從HTTP到MIME兼容協(xié)議的代理和網(wǎng)關(guān)要負責(zé)保證協(xié)議上消息格式正確及編碼傳輸

安全孙技，所謂安全傳輸是指滿足對應(yīng)協(xié)議所規(guī)定的限制或約束標(biāo)準(zhǔn)产禾。代理或網(wǎng)關(guān)應(yīng)當(dāng)用適當(dāng)?shù)?/p>

內(nèi)容傳輸編碼（Content-Transfer-Encoding）來標(biāo)識數(shù)據(jù)，以提高在目的協(xié)議上實現(xiàn)安全傳輸

的可能性牵啦。

C.5? 多個主體的HTTP標(biāo)題域（HTTP Header Fields in

Multipart Body-Parts）

在RFC1521中亚情，大多數(shù)多個主體組成的標(biāo)題域通常會被忽略，除非其域名以"Content-"開

頭哈雏。在HTTP/1.0中楞件，多個主體部分（multipart body-parts）所包含的任何HTTP標(biāo)題域衫生，只

對對應(yīng)的部分有意義。

D.? 附加特性（Additional Features）

該附錄中包括的一些協(xié)議元素存在于一些HTTP實現(xiàn)中土浸，但并非對所有的HTTP/1.0的

應(yīng)用都適用罪针。開發(fā)者應(yīng)注意這些特性，但不能依賴它們來與其它的HTTP/1.0應(yīng)用程序進行

交互黄伊。

D.1? 附加請求方法（Additional Request Methods）

D.1.1 PUT

PUT方法請求服務(wù)器將附件的實體儲存在提供的請求URI處泪酱。如果該請求URI指向的

資源已經(jīng)存在，則附件實體應(yīng)被看做是當(dāng)前原始服務(wù)器上資源的修改版本还最。如果請求URI

沒有指向現(xiàn)存的資源墓阀，該URI將被該請求的用戶代理定義成為一個新的資源，原始服務(wù)器

將用該URI產(chǎn)生這個資源憋活。

POST與PUT兩種請求的基本區(qū)別在于對請求URI的理解不同岂津。在POST請求方法中

的URI所標(biāo)識的資源將做為附件實體被服務(wù)器處理，該資源可能是數(shù)據(jù)接收處理過程悦即、某

些其它協(xié)議的網(wǎng)關(guān)吮成、或可被注釋的單獨實體。與此相反辜梳，用戶代理很清楚它發(fā)出的PUT請

求中附帶URI所標(biāo)識的實體指向何處粱甫，而服務(wù)器處不應(yīng)將該請求用到其它資源頭上。

D.1.2 DELETE

DELETE方法請求原始服務(wù)器刪除由請求URI所指定的資源作瞄。

D.1.3 LINK

LINK方法建立與請求URI所指定資源或其它已存在資源之間的一個或多個連接關(guān)系茶宵。

D.1.4 UNLINK

UNLINK方法刪除與請求URI所指定資源之間的一個或多個連接關(guān)系。

D.2? 附加標(biāo)題域定義（Additional Header Field Definitions）

D.2.1 Accept

Accept請求標(biāo)題域用于指示可被接受的請求回應(yīng)的介質(zhì)范圍列表宗挥。星號"*"用于按范圍

將介質(zhì)類型分組乌庶，用"*/*"指示可接受全部介質(zhì)類型；用"type/*"指示可接受type類型的所有

子類型契耿。對于給定請求的上下文瞒大，客戶端應(yīng)當(dāng)表示出哪些類型是它可以接受的。

D.2.2 可接受的字體集（Accept-Charset）

Accept-Charset請求標(biāo)題域用來指示除了US-ASCII和ISO-8859-1外搪桂，首選的字符集透敌。

該域?qū)⑹箍蛻舳擞心芰斫飧鼜V泛的或有特殊用途的字符集，從而在服務(wù)器上可以存放采用

此類字符集的文檔踢械。

D.2.3 可接受編碼（Accept-Encoding）

Accept-Encoding請求標(biāo)題域與Accept相似酗电，但是限制了回應(yīng)中可接受的內(nèi)容編碼

（content-coding）值。

D.2.4 可接受語言（Accept-Language）

Accept-Language請求標(biāo)題域與Accept相似内列，但限制了請求回應(yīng)中首選的自然語言集撵术。

D.2.5 內(nèi)容語言（Content-Language）

Content-Language實體標(biāo)題域描述了附加實體中為聽眾指定的自然語言。注意德绿，這可能

與在實體內(nèi)部使用的各種語言不是一碼事荷荤。

D.2.6 連接（Link）

Link實體標(biāo)題域描述了實體和某些其它資源之間的關(guān)系退渗。一個實體可能包括多個連接

值。處于元信息級的Link指明了分層結(jié)構(gòu)和導(dǎo)航路徑之間的關(guān)系蕴纳。

D.2.7 MIME版本（MIME-Version）

HTTP消息可能包括一個單獨的MIME版本的普通標(biāo)題（general-header）域会油，用以指示

用來構(gòu)造消息的MIME協(xié)議的版本。MIME版本標(biāo)題域的使用古毛，正如RFC1521[5]中定義的

那樣翻翩，應(yīng)當(dāng)用來指示消息是否符合MIME規(guī)范。然而不幸的是稻薇，一些老的HTTP/1.0服務(wù)器

不加選擇地發(fā)送此域嫂冻，導(dǎo)致此域已經(jīng)被廢棄。

D.2.8 在….后重試（Retry-After）

Retry-After回應(yīng)標(biāo)題域可與503（服務(wù)不可用）回應(yīng)一起使用塞椎，用于指示服務(wù)器停止響

應(yīng)客戶請求的時間長短桨仿。該域的值可用HTTP格式的日期表示，也可以用整數(shù)來表示回應(yīng)時

間后的秒數(shù)案狠。

D.2.9 標(biāo)題（Title）

Title實體標(biāo)題域用于指示實體的標(biāo)題服傍。

D.2.10 URI

URI實體標(biāo)題域可能包含一些或全部統(tǒng)一資源標(biāo)識（Uniform Resource Identifiers），見

3.2節(jié)骂铁，通過這些標(biāo)識來表示請求URI所指定的資源吹零。并不擔(dān)保根據(jù)URI一定能夠找到指定

的資源。

RFC1945——Hyptertext Transfer Protocol – HTTP/1.0? ? ? ? ? ? ? ? ? 超文本傳輸協(xié)議1.0

1

RFC文檔中文翻譯計劃