8.? 方法定義（Method Definitions）

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

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

8.1? GET

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

數據產生過程，那么最終要在回應實體中返回的是由該處理過程的結果所指向的資源，而不

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

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

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

標題域（見10.9節）中的指定日期后發生了更新，才啟動傳輸，否則不傳輸。這種條件GET

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

網絡負載。

8.2? HEAD

HEAD方法與GET幾乎一樣，區別在于，HEAD方法不讓服務器在回應中返回任何實

體。對HEAD請求的回應部分來說，它的HTTP標題中包含的元信息與通過GET請求所得

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

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

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

請求中指定If-Modified-Since標題域，它也會被忽略。

8.3? POST

POST方法用來向目的服務器發出請求，要求它接受被附在請求后的實體，并把它當作

請求隊列（Request-Line）中請求URI所指定資源的附加新子項。POST被設計成用統一的

方法實現下列功能：

o 對現有資源的注釋（Annotation of existing resources）；

o 向電子公告欄、新聞組，郵件列表或類似討論組發送消息；

o 提交數據塊，如將表格（form [3]）的結果提交給數據處理過程；

o 通過附加操作來擴展數據庫。

POST方法的實際功能由服務器來決定，而且通常依賴于請求URI。在POST過程中，

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

的新聞組、記錄從屬于其所在的數據庫一樣。

成功的POST不需要在原始服務器創建實體，并將其做為資源；也不需要為未來的訪問

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

功）或204（無內容）都是適當的回應狀態，取決于實際回應實體中對結果的描述。

如果在原始服務器上創建了資源，回應應是201（已創建），并包含一個實體

（對"text/html"類型最為適合），該實體中記錄著對新資源請求的狀態描述。

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

果HTTP/1.0服務器在接收到請求消息內容時無法確定其長度，就會返回400（非法請求）

代碼。

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

務器在未來的請求中將如何回應。

9.? 狀態代碼定義（Status Code Definitions）

每個狀態代碼都將在下面描述，包括它們將對應哪個方法、以及回應中需要的全部元信

息。

9.1? 消息1xx（Informational 1xx）

該類狀態代碼用于表示臨時回應。臨時回應由狀態行（Status-Line）及可選標題組成，

由空行終止。HTTP/1.0中沒有定義任何1xx的狀態代碼，所以它們不是對HTTP/1.0請求的

合法回應。實際上，它們主要用于實驗用途，這已經超出本文檔的范圍。

9.2? 成功2xx（Successful 2xx）

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

200 OK

請求成功。回應的信息依賴于請求所使用的方法，如下：

GET 要請求的資源已經放在回應的實體中了。

HEAD 沒有實體主體，回應中只包括標題信息。

POST 實體（描述或包含操作的結果）。

201 Created

請求完成，結果是創建了新資源。新創建資源的URI可在回應的實體中得到。原

始服務器應在發出該狀態代碼前創建該資源。如果該操作不能立即完成，服務器必

須在該資源可用時在回應主體中給出提示，否則，服務器端應回應202（可被接受）。

在本文定義的方法，只有POST可以創建資源。

202 Accepted

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

時中斷，在這種情況下，沒有辦法在異步操作中重新發送狀態代碼。

202回應是沒有義務的，這樣做的目的是允許服務器不必等到用戶代理和服務器間

的連接結束，就可以響應其它過程的請求（象每天運行一次的，基于批處理的過程）。

在某些回應中返回的實體中包括當前請求的狀態指示、狀態監視器指針或用戶對請

求能否實現的評估信息。

204 No Content

服務器端已經實現了請求，但是沒有返回新的信息。如果客戶是用戶代理，則勿需

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

提下，進行script語句的輸入及其它操作。該回應還可能包括新的、以實體標題形

式表示的元信息，它可被當前用戶代理激活視圖中的文檔所使用。

9.3? 重定向（Redirection 3xx）

該類狀態碼表示用戶代理要想完成請求，還需要發出進一步的操作。這些操作只有

當后跟的請求是GET或HEAD時，才可由用戶代理來實現，而不用與用戶進行交

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

環。

300 Multiple Choices

該狀態碼不被HTTP/1.0的應用程序直接使用，只是做為3xx類型回應的缺省解釋。

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

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

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

如果服務器有首選，它應將對應的URL信息存放在位置域（Location field）處，

用戶代理會根據此域的值來實現自動的重定向。

301 Moved Permanently

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

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

請求URI。

新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體

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

如果用POST方法發出請求，而接收到301回應狀態碼。在這種情況下，除非用戶

確認，否則用戶代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

注意：當在接收到301狀態碼后而自動重定向POST請求時，一些現存的用戶代理

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

302 Moved Temporarily

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

應繼續用請求URI來發出以后的請求。

新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體

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

如果用POST方法發出請求，而接收到302回應狀態碼。在這種情況下，除非用戶

確認，否則用戶代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

注意：當在接收到302狀態碼后而自動重定向POST請求時，一些現存的用戶代理

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

304 Not Modified

如果客戶端成功執行了條件GET請求，而對應文件自If-Modified-Since域所指定

的日期以來就沒有更新過，服務器應當回應此狀態碼，而不是將實體主體發送給客

戶端。回應標題域中只應包括一些相關信息，比如緩存管理器、與實體最近更新

（entity's Last-Modified）日期無關的修改。相關標題域的例子有：日期、服務器、

過期時間。每當304回應中給出的域值發生變化，緩存都應當對緩存的實體進行更

新。

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

4xx類的狀態碼表示客戶端發生錯誤。如果客戶端在收到4xx代碼時請求還沒有完成，

它應當立即終止向服務器發送數據。除了回應HEAD請求外，不論錯誤是臨時的還是永久

的，服務器端都必須在回應的實體中包含錯誤狀態的解釋。這些狀態碼適用于任何請求方法。

注意：如果客戶端正在發送數據，服務器端的TCP實現應當小心，以確保客戶端在關

閉輸入連接之前收到回應包。如果客戶端在關閉后仍舊向服務器發送數據，服務器會給客戶

端發送一個復位包，清空客戶端尚未處理的輸入緩沖區，以終止HTTP應用程序的讀取、解

釋活動。

400 非法請求（Bad Request）

如果請求的語法不對，服務器將無法理解。客戶端在對該請求做出更改之前，不應

再次向服務器重復發送該請求。

401 未授權（Unauthorized）

請求需要用戶授權。回應中的WWW-Authenticate標題域（10.16節）應提示用戶

以授權方式請求資源。客戶端應使用合適的授權標題域（10.2節）來重復該請求。如果

請求中已經包括了授權信任信息，那回應的401表示此授權被拒絕。如果用戶代理在多

次嘗試之后，回應一樣還是返回401狀態代碼，用戶應當察看一下回應的實體，因為在

實體中會包括一些相關的動態信息。HTTP訪問授權會在11節中解釋。

403 禁止（Forbidden）

服務器理解請求，但是拒絕實現該請求。授權對此沒有幫助，客戶端應當停止重復

發送此請求。如果不是用HEAD請求方法，而且服務器端愿意公布請求未被實現原因

的前提下，服務器會將拒絕原因寫在回應實體中。該狀態碼一般用于服務器端不想公布

請求被拒絕的細節或沒有其它的回應可用。

404 沒有找到（Not Found）

服務器沒有找到與請求URI相符的資源。404狀態碼并不指明狀況是臨時性的還是

永久性的。如果服務器不希望為客戶端提供這方面的信息，還回應403（禁止）狀態碼。

9.5? 服務器錯誤（Server Error ）5xx

回應代碼以‘5’開頭的狀態碼表示服務器端發現自己出現錯誤，不能繼續執行請

求。如果客戶端在收到5xx狀態碼時，請求尚未完成，它應當立即停止向服務器發送數

據。除了回應HEAD請求外，服務器應當在其回應實體中包括對錯誤情況的解釋、并

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

這類回應代碼沒有標題域，可適用于任何請求方法。

500 服務器內部錯誤（Internal Server Error）

服務器碰到了意外情況，使其無法繼續回應請求。

501 未實現（Not Implemented）

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

應此狀態代碼，這意味著不能回應請求所要求的任何資源。

502 非法網關（Bad Gateway）

充當網關或代理的服務器從要發送請求的上游（upstream）服務器收到非法的回應。

503 服務不可用（Service Unavailable）

服務器當前無法處理請求。這一般是由于服務器臨時性超載或維護引起的。該狀態

碼暗示情況是暫時性的，要產生一些延遲。

注意：503狀態碼并沒有暗示服務器在超載時一定要返回此狀態碼。一些服務器可

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

10.? 標題域定義（Header Field Definitions）

本節定義了HTTP/1.0標題域常用的語法及語義。無論是發送方還是接收方，都有

可能做為客戶端或服務器端，具體角色取決于在此時刻究竟是誰在接收、誰在發送。

10.1? 允許（Allow）

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

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

要這么做，將被忽略。

Allow = "Allow" ":" 1#method

Example of use:

Allow: GET, HEAD

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

信息是有用的，應當被遵守。實際的Allow方法集在每次向原始服務器上發出請求時定

義。

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

來說，即使無法識別請求所指定的所有方法，也不能修改該請求的Allow標題域。

Allow標題域并不表示服務器實現了哪些方法。

10.2? 授權（Authorization）

通常，用戶代理在收到401（未授權）回應時，可能（也可能不會）希望服務器對其授

權。如果希望授權，用戶代理將在請求中加入授權請求標題（Authorization request-header）

域。授權域值由信任證書組成，其中有對用戶代理所請求資源領域的授權信息。

Authorization? = "Authorization" ":" credentials

HTTP訪問授權在11節中描述。如果請求中的授權指定了一個范圍，那在此范圍的其

它請求也都具有相同的信任關系。

對包含授權信息域的請求來說，其回應是不能被緩存的。

10.3? 內容編碼（Content-Encoding）

內容編碼的實體標題域（entity-header）用作介質類型（media-type）的修飾符。它指明

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

介質類型，必須采用與譯碼方式一致的解碼機制。內容編碼主要用來記錄文件的壓縮方法。

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

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

內容譯碼（Content codings）在3.5節中定義，例如：

Content-Encoding: x-gzip

內容編碼是請求URI指定資源的一個特性，一般來說，資源用編碼方式存儲，只有在

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

10.4? 內容長度（Content-Length）

內容長度（Content-Length）實體標題域指明了發送到接收方的實體主體（Entity-Body）

長度，用字節方式存儲的十進制數字表示。對于HEAD方法，其尺寸已經在前一次GET請

求中發出了。

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

例如：

Content-Length: 3495

不論實體是何種介質類型，應用程序都將通過該域來判定將要傳輸的實體主體尺寸。所

有包括實體主體的HTTP/1.0的請求消息都必須包括合法的內容長度值。

任何0以上（包括0）的值都是合法的內容長度值。在7.2.2節描述了當內容長度值沒

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

注意：該域的含義與在MIME中定義的有重要區別。在MIME中，它是可選域，只

在"message/external-body"內容類型中使用；而在HTTP中，在實體被傳輸前，該域就決定

了實體的長度。

10.5? 內容類型（Content-Type）

內容類型實體標題域指明了發送給接收方的實體主體長度。對于HEAD方法，介質類

型已經在前一次GET請求中發出了。

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

介質類型在3.6節中定義，如下例：

Content-Type: text/html

更多關于介質類型的討論在7.2.1節。

10.6? 日期（Date）

日期普通標題（Date general-header）域表示消息產生的時間，其語法與RFC822中定義

的orig-date是一樣的。該域值是HTTP型日期，在3.3節中描述。

Date = "Date" ":" HTTP-date

例如：

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

如果直接通過用戶代理（如請求）或原始服務器（如回應）的連接接收到消息，日期可

以認為是接收端的當前時間。然而，對于原始服務器來說，時間對其回應緩存的處理非常重

要，所以，原始服務器的回應總是包括日期標題。客戶端只有在發送帶實體的消息時，才可

向服務器發送日期標題域，比如POST請求。如果接收到的消息被接收方或網關通過有日期

要求的協議緩存起來時，該消息即使沒有日期標題域，接收方也會為其分配一個。

理論上，日期應當在實體產生時生成，而實際上，日期可能在消息產生過程的任意時間

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

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

正。

10.7? 過期（Expires）

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

息失效的手段。當超過此期限時，應用程序不應再對此實體進行緩存了。過期并不意味著原

始資源會在此期限后發生改變或停止存在。在實際應用中，信息提供者通過檢查過期標題域

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

間（3.2節）。

Expires = "Expires" ":" HTTP-date

例如：

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

如果給定日期比日期標題中的要早（或相同），接收方不應緩存附加的實體。如果資源

是動態自然生成的，象有些大量數據的處理，資源的實體應當被加上一個適當的過期時間值。

過期域并不能強制用戶代理對其進行刷新或重新載入資源，它只用于緩存機制。當對已

初始化過的資源發出新請求時，該機制才檢查該資源的過期狀態。

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

重新顯示某次對話（session）之前已經獲取的實體信息。在缺省狀態下，過期域不對歷史機

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

存著，歷史機制就能顯示它，不論該實體是否已經過期。

注意：應用程序應兼容對過期標題非法或錯誤的實現，如碰到0值或非法的日期格式，

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

于一個健壯的應用來說，還是必要的。

10.8? 來自（From）

From請求標題域，如果給出來，則應包括一個使用此用戶代理的人類用戶的Internet

e-mail地址。該地址應當能被系統識別，就象RFC822[7]（已經更新為RFC1123[6]）中的郵

箱定義一樣。

From = "From" ":" mailbox

例如：

From: webmaster@w3.org

該標題域可能用來做為登錄目的使用，以確定對某資源的請求是否合法。它不應用于不

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

種方式負責。特殊情況下，機器人（robot）代理也應包括此標題域，域中注明是誰運行它

的，這樣，當接收端發生任何問題時，都可以同這個人取得聯系。

該域中的Internet e-mail地址可以與處理該請求的Internet主機分離。例如，當請求通過

代理（proxy）時，應使用原始的傳輸地址。

注意：客戶端在沒有得到用戶批準時，不應發送From標題域，因為這樣做可能會產生

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

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

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

If-Modified-Since請求標題域和GET方法一起使用，用于處理下面情況：當在該域指定

的日期以來，請求資源沒有發生任何變更。這時，服務器將不會下傳該資源的拷貝，即，回

應不帶任何實體主體，只是304狀態碼（未修改）。

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

例如：

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

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

的指定資源下傳，也就是說，如果資源沒發生變化，就不下傳了。其算法如下：

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

日期不合法，此時按照普通GET來回應。如果日期比服務器的當前時間還要

晚，則是非法時間。

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

c) 如果資源在If-Modified-Since日期以后沒變化，服務器端將回應304（未修改）。

注：該日期應是合法的。

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

10.10? 最近更改（Last-Modified）

Last-Modified實體標題域表示由發送方設定的資源最近修改日期及時間。該域的精確定

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

所指定的要舊，該拷貝就是過期的。

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

例如：

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

該標題域的精確含義取決于發送方的執行方式及原始資源的自然狀態。對于文件來說，

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

部分中最新的last-modify時間。對數據庫網關來說，可能是記錄的last-update時間戳。對于

虛（virtual）對象來說，可能是內部狀態的最近改變時間。

原始服務器不應發送比服務器消息產生時間更晚的Last-Modified日期，因為該消息會

導致服務器在未來的某個時間內，用消息原始的日期對該域值進行再次更新。

10.11? 位置（Location）

Location回應標題域定義了由請求URI指定的資源的位置。對于3xx（重定向）回應，

位置域必須能幫助服務器找到相應的URL，以實現對資源的重定向。只允許用絕對URL。

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

例如：

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

10.12? 注解（Pragma）

Prama普通標題域包括一些可能對請求/回應鏈中的任一接收方有用的特殊指示信息。

從協議角度看，所有的注解指示了一些特定的可選行為，事實上，一些系統可能會要求行為

與指示一致。

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

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

extension-pragma = token [ "=" word ]

當"no-cache"出現在請求消息中時，應用程序應當向原始服務器推送此請求，即使它已

經在上次請求時已經緩存了一份拷貝。這樣將保證客戶端能接收到最權威的回應。它也用來

在客戶端發現其緩存中拷貝不可用或過期時，對拷貝進行強制刷新。

不管注解（Pragma）指示信息對代理（proxy）及網關（gateway）應用程序如何重要，

它必須能穿越這些應用，因為該信息可能對請求/回應鏈上的其它接收方有用。實際上，如

果注解與某個接收方無關，它應當被該接收方忽略。

10.13 提交方（Referer）

提交方請求標題域是出于服務器端利益方面的考慮，允許客戶端指明該鏈接的出處，即

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

列表，用于維護受歡迎的資源、登錄、緩存優化等活動。

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

例子：

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

如果只給了部分URI，應當參照請求URI來解釋它。URI不能包括段（fragment）。

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

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

表單信息的發送。

10.14? 服務器（Server）

服務器回應標題域包含由原始服務器用來處理請求的軟件信息。該域可包含多個產品標

識（3.7節）及注釋以標識服務器及重要的子產品。按照習慣，產品標識將按其應用的重要

順序排列。

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

例如：

Server: CERN/3.0 libwww/2.17

如果回應要通過代理來推送，代理應用程序不應將它自己的數據加入產品列表。

注意：一些指定服務器軟件的版本有啟示作用，因為這些版本的軟件存在一些安全漏洞，

將使服務器更易受到攻擊。提倡服務器軟件在實現時，將此域變成可以進行配置的選項。

注意：有些服務器不遵守服務器域產品標識的語法約束。

10.15? 用戶代理（User-Agent）

用戶代理請求標題域包含用戶原始請求的信息，這可用于統計方面的用途。通過跟蹤協

議沖突、自動識別用戶代理以避免特殊用戶代理的局限性，從而做到更好的回應。雖然沒有

規定，用戶代理應當在請求中包括此域。該域可包含多個產品標識（3.7節）及注釋以標識

該代理及其重要的子產品。按照習慣，產品標識將按子產品對應用的重要性順序排列。

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

例如：

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

注意：現存有些代理應用將它們的產品信息回到了用戶代理域中，這種方法不值得提倡，

因為這樣做會使機器在解釋這些信息時產生混淆。

注意：現在有些客戶端不遵守用戶代理域中產品標識的語法約束。

10.16? WWW-授權（WWW-Authenticate）

WWW-授權回應標題域必須被包括在401（未授權）回應消息中。該域值由一個以上的

challenge組成，這些challenge可用于指出請求URI的授權方案及參數。

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

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

看它是否包含一個以上的待解決問題（challenge）或是否提供了一個以上的WWW-授權標

題域，因為待解決問題（challenge）的內容中可能包含用逗號分隔的授權參數列表。

11.? 訪問鑒別（Access Authentication）

HTTP提供了一個簡單的質詢回應（challenge-response）鑒別機制，可用于服務器通過

客戶端提供的授權信息來對其進行身份鑒別。授權方案用可擴展的、大小寫敏感的符號來標

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

auth-scheme? ? = token

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

原始服務器用401（未授權）回應消息來質詢用戶代理的授權。該回應必須包括WWW-

授權標題域，而該WWW-授權標題域包括一個以上用于請求資源認證的參數（challenge）。

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

realm = "realm" "=" realm-value

realm-value = quoted-string

凡涉及到參數（challenge）處理的授權方案都有realm屬性（大小寫敏感）。與標準URL

（相對于被訪問服務器root）聯合使用的realm值（也是大小寫敏感）用來定義保護區域。

Realm使得服務器上的被保護資源被放在特殊的保護分區內，這些區域都有各自的授權方案

和（或）授權數據庫。Relm值是個字符串，通常由原始服務器來分配，對于授權方案來說，

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

通常，用戶代理在收到401（未授權）回應時，可能（也可能不會）希望服務器對其授

權。如果希望授權，用戶代理將在請求中加入授權請求標題（Authorization request-header）

域。授權域值由信任證書組成，其中有對用戶代理所請求資源領域的授權信息。

credentials? ? = basic-credentials

| ( auth-scheme #auth-param )

可由用戶代理通過信任方式來訪問的區域由保護區域決定。如果早先的請求已經通過認

證，在由授權方案，參數和（或）用戶選擇等所指定的時間間隔內，其它的請求可通過相同

的信任來訪問該保護區域。

除非由授權另行指定，否則單個保護區域的范圍不能擴展到服務器之外。

如果服務器不希望通過請求來接受信任，它應當返回403（禁止）回應。

HTTP協議的訪問授權不限于這種簡單的質詢回應（challenge-response）機制，還可以

使用其它的方法，比如傳輸級加密或消息封裝及通過附加標題域來指定授權信息等等。但是，

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

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

WWW-授權及授權標題向前推送，也不可以對包含授權的回應進行緩存。HTTP/1.0不為客

戶端提供通過代理方式授權的方法。

11.1? 基本授權方案（Basic Authentication Scheme）

用戶代理必須對于每個領域（realm）通過用戶標識（user-ID）及口令來對自身進行授

權，這是基本授權方案的工作模式。Realm值應當被看作不透明的字符串，該值將用于同服

務器端其它的realm值相比較。只有用戶標識及口令通過受保護資源的認證，服務器才會給

請求授權。授權參數沒有可選項。

在接收到對受保護區域的未經認證的資源請求時，服務器應當回應一個質詢

（challenge），如下：

WWW-Authenticate: Basic realm="WallyWorld"

"WallyWorld"是由服務器分配的字符串，用于對請求URI所指定的受保護資源進行標

識。

為了接收授權，客戶端需要在基于64位（base64 [5]）的證書中發送用戶標識及口令，

中間用冒號':'分隔。

basic-credentials = "Basic" SP basic-cookie

basic-cookie? ? ? =

except not limited to 76 char/line>

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

如果用戶代理希望發送用戶標識"Aladdin"和口令“open sesame”，應當遵循下面的標題

域形式：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basic授權方案是對HTTP服務器資源的非授權訪問進行過濾的非安全方法。它基于假

定客戶端與服務器端的連接是安全的，為什么說是假定呢，因為在實際的開放性網絡中，使

用basic授權方案往往存在許多不安全的地方。盡管如此，客戶端仍然需要實現此方案，以

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

12.? 安全考慮（Security Considerations）

本節的描述對下面各角色有關：信息應用開發者、信息提供者、HTTP/1.0中受安全性

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

終解決辦法。

12.1? 客戶授權（Authentication of Clients）

正如11.1節中所述，基本授權（Basic authentication）方案不是安全的用戶授權方案，

也不能用它來防止實體主體源碼以文本方式在物理網絡中傳輸。HTTP/1.0并不反對在目前

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

12.2? 安全方法（Safe Methods）

客戶端軟件開發者應當注意，客戶端軟件代表用戶在Internet上與其它方面交互，并應

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

息。

特別情況下，按協定來看，GET和HEAD方法應被視作是安全的，同重新獲得數據應

當沒有什么不同。這就允許用戶代理采用其它方法，如POST，在某種情況下，可能存在這

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

通常，服務器端在執行過GET請求之后，其結果之類的副產品還殘留在服務器上；實

際上，一些動態資源需要這種特性來實現。這里的重要區別在于用戶沒有請求這些副產品，

因而也不應當對這類請求進行解釋。

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

Information）

服務器為保存與用戶請求相關的個人數據，如閱讀方式或感興趣的主題等提供了空間。

這些存儲信息顯然是受某些國家法律保護的，所以對此類數據的處理應當小心。用HTTP

協議提供數據的一方應當負責保證這些信息在未得各方許可之前不會散布出去。

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

與其它協議一樣，HTTP協議不能調整傳輸數據的內容，也不存在未卜先知的方法，通

過給定請求的上下文信息片段就能推測出信息的敏感程度。因而，應用程序應當盡可能像信

息提供方一樣，為該信息提供更多的控制。在此，有三個標題域值得一提：服務端（Server）、

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

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

服務器更易受到攻擊。提倡服務器軟件在實現時，將Server標題域變成可以進行配置的選

項。

提交方（Referer）標題域允許閱讀方式（reading patterns）被暴露，并可導出反向鏈接。

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

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

這可能是該信息發布者所不想看到的。

來自（From）標題域可能包括一些與用戶私人隱私及站點安全相關的信息，因而，在

發送數據前，應當允許用戶使用一些設定手段，如禁止（disable）、允許（enable）、及修改

（modify），對此域信息進行配置。用戶應當能夠根據他們的選擇或使用應用程序提供的缺

省配置來設定此域的內容。

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

送From域或Referer域的信息。

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

Path Names）

HTTP原始服務器的實現應當注意，要對以服務器管理員名義發出的，對某個文件的

HTTP請求進行限制。如果HTTP服務器直接將HTTP URI發送給系統調用，服務器要特別

注意，當某個請求文件不是發往HTTP客戶端時，要予以拒絕服務。例如，在Unix、Microsoft

Windows以及其它的操作系統使用".."做為上級目錄名。在這樣的系統下，HTTP服務器端

必須禁止通過使用這種結構的請求URI來訪問HTTP服務器其它范圍的資源。同樣，服務

器端內部使用的一些文件，包括訪問控制文件，配置文件、script代碼等，也要受到特別保

護，以避免被非法請求獲取，導致系統敏感信息暴露。實驗證明，哪怕是最小的bug，也可

能導致嚴重的安全問題。

13.? 感謝（Acknowledgments）

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

中定義的一般結構。同樣，它使用了許多由Nathaniel Borenstein和Ned Freed為MIME [5]

做的許多定義。我們希望通過它們來減少對HTTP/1.0及mail消息格式之間關系的混淆。

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

參與WWW討論郵件列表的人們，造就了HTTP在全球范圍內的成功。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，他們為本文檔早期版本投入了巨大精力。Paul Hoffman

提供了關于信息狀態方面的信息，以及附錄C、D的內容。

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

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）

這些信息出現在附錄中僅有一個理由，即他們沒有成為HTTP/1.0規范的組成部分。

A.? Internet介質類型消息/http（Internet Media Type

message/http）

做為HTTP/1.0協議的補充，該文檔做為Internet介質類型"message/http"的規范。下面

內容被登記在IANA[13]中。

介質類型名（Media Type name）： message

介質子類型名（Media subtype name）： http

請求參數（Required parameters）： none

可選參數項（Optional parameters）： version, msgtype

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

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

消息類型（msgtype）：消息類型――請求（request）或回應（response）。如果

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

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

安全考慮（Security considerations）： none

B.? 容錯應用（Tolerant Applications）

雖然此文檔指明了產生HTTP/1.0消息的必要條件，并非所有的應用程序都校正他們的

實現。因此，我們建議應用程序增強其容錯能力，以便在岐義仍可被明確解釋時，還能保證

正常運行。

客戶端解析狀態行（Status-Line）及服務器解析請求行（Request-Line）時，應當做到容

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

符分隔的域。

HTTP標題域的行終止符是順序字符CRLF。而我們建議應用程序在解析這類標題時，

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

C.? 與MIME的關系（Relationship to MIME）

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

（Multipurpose Internet Mail Extensions）MIME[5]定義的結構，以允許實體通過一種開放的

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

區別被用來優化二進制傳輸的性能，給介質類型的使用提供了更大的自由度，使日期比較變

得更加容易，當然，這也是為了兼容早期的一些HTTP服務器及客戶端的應用。

在寫作本文時，據說RFC1521將被修訂。修訂版本將會包括一些出現在HTTP/1.0中的

已有的應用，但這些應用在目前的RFC1521中尚未包括。

該附錄描述了HTTP與RFC1521中的不同之處。代理和網關在限制MIME環境時，應

當注意到這些區別，并在必須時提供相應的轉換支持。從MIME到HTTP環境的代理和網

關也要注意這些區別，因為一些轉換可能是必須的。

C.1? 轉換為規范形式（Conversion to Canonical Form）

RFC1521要求Internet郵件實體在被傳輸前轉換成規范形式，正如RFC1521[5]附錄C

中所描述的那樣。本文檔中3.6.1節中描述了HTTP在傳輸時允許的“text”介質類型的子類

型的具體形式。

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

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

只要有可能，HTTP環境或RFC1521環境下的代理或網關應當將本文檔3.6.1節中描述

的文本介質類型中的所有行中斷符都轉換成CRLF。注意，由于存在著內容編碼

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

13和10做為CR和LF，這樣就使實際的處理更加復雜。

C.2? 日期格式轉換（Conversion of Date Formats）

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

和網關應當保證消息中的任何日期標題域與HTTP/1.0格式一致，否則，要對其進行改寫。

C.3? 內容編碼介紹（Introduction of Content-Encoding）

RFC1521不包括殊如HTTP/1.0中內容編碼標題域之類的概念。由于內容類型域是介質

類型的修飾，因而從HTTP到MIME兼容協議中的代理和網關必須在將消息向前推送之前，

更改內容類型標題域（Content-Type）的值或者對實體主體（Entity-Body）進行解碼（有些

Internet mail內容類型的實驗性應用采用介質類型參數為";conversions="來

替代內容解碼，而事實上，該參數并非RFC1521的組成部分）。

C.4? 無內容傳輸編碼（No Content-Transfer-Encoding）

HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域。與MIME協議兼容的

代理和網關在向HTTP客戶端傳遞回應消息前都必須清除任何無標識的CTE編碼

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

從HTTP到MIME兼容協議的代理和網關要負責保證協議上消息格式正確及編碼傳輸

安全，所謂安全傳輸是指滿足對應協議所規定的限制或約束標準。代理或網關應當用適當的

內容傳輸編碼（Content-Transfer-Encoding）來標識數據，以提高在目的協議上實現安全傳輸

的可能性。

C.5? 多個主體的HTTP標題域（HTTP Header Fields in

Multipart Body-Parts）

在RFC1521中，大多數多個主體組成的標題域通常會被忽略，除非其域名以"Content-"開

頭。在HTTP/1.0中，多個主體部分（multipart body-parts）所包含的任何HTTP標題域，只

對對應的部分有意義。

D.? 附加特性（Additional Features）

該附錄中包括的一些協議元素存在于一些HTTP實現中，但并非對所有的HTTP/1.0的

應用都適用。開發者應注意這些特性，但不能依賴它們來與其它的HTTP/1.0應用程序進行

交互。

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

D.1.1 PUT

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

資源已經存在，則附件實體應被看做是當前原始服務器上資源的修改版本。如果請求URI

沒有指向現存的資源，該URI將被該請求的用戶代理定義成為一個新的資源，原始服務器

將用該URI產生這個資源。

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

的URI所標識的資源將做為附件實體被服務器處理，該資源可能是數據接收處理過程、某

些其它協議的網關、或可被注釋的單獨實體。與此相反，用戶代理很清楚它發出的PUT請

求中附帶URI所標識的實體指向何處，而服務器處不應將該請求用到其它資源頭上。

D.1.2 DELETE

DELETE方法請求原始服務器刪除由請求URI所指定的資源。

D.1.3 LINK

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

D.1.4 UNLINK

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

D.2? 附加標題域定義（Additional Header Field Definitions）

D.2.1 Accept

Accept請求標題域用于指示可被接受的請求回應的介質范圍列表。星號"*"用于按范圍

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

子類型。對于給定請求的上下文，客戶端應當表示出哪些類型是它可以接受的。

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

Accept-Charset請求標題域用來指示除了US-ASCII和ISO-8859-1外，首選的字符集。

該域將使客戶端有能力理解更廣泛的或有特殊用途的字符集，從而在服務器上可以存放采用

此類字符集的文檔。

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

Accept-Encoding請求標題域與Accept相似，但是限制了回應中可接受的內容編碼

（content-coding）值。

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

Accept-Language請求標題域與Accept相似，但限制了請求回應中首選的自然語言集。

D.2.5 內容語言（Content-Language）

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

與在實體內部使用的各種語言不是一碼事。

D.2.6 連接（Link）

Link實體標題域描述了實體和某些其它資源之間的關系。一個實體可能包括多個連接

值。處于元信息級的Link指明了分層結構和導航路徑之間的關系。

D.2.7 MIME版本（MIME-Version）

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

用來構造消息的MIME協議的版本。MIME版本標題域的使用，正如RFC1521[5]中定義的

那樣，應當用來指示消息是否符合MIME規范。然而不幸的是，一些老的HTTP/1.0服務器

不加選擇地發送此域，導致此域已經被廢棄。

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

Retry-After回應標題域可與503（服務不可用）回應一起使用，用于指示服務器停止響

應客戶請求的時間長短。該域的值可用HTTP格式的日期表示，也可以用整數來表示回應時

間后的秒數。

D.2.9 標題（Title）

Title實體標題域用于指示實體的標題。

D.2.10 URI

URI實體標題域可能包含一些或全部統一資源標識（Uniform Resource Identifiers），見

3.2節，通過這些標識來表示請求URI所指定的資源。并不擔保根據URI一定能夠找到指定

的資源。

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

1

RFC文檔中文翻譯計劃