rfc1945-http1.0自譯本-(7) (轉)

rfc1945-http1.0自譯本-(7) (轉)[@more@] 

10.7  過期（Expires）

 

  過期實體標題域中的日期/時間值指定了實體過期的時間。這為資訊提供方提供了使資訊失效的手段。當超過此期限時，應用不應再對此實體進行快取了。過期並不意味著原始資源會在此期限後發生改變或停止存在。在實際應用中，資訊提供者透過檢查過期標題域中所指定的時間，從而獲知或預測資源將會發生改變的確切日期。該格式用的是絕對日期時間（3.2節）。

 :namespace prefix = o ns = "urn:schemas--com::office" />

Expires  = "Expires" ":" HTTP-date

 

例如：

 

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

 

如果給定日期比日期標題中的要早（或相同），接收方不應快取附加的實體。如果資源是動態自然生成的，象有些大量資料的處理，資源的實體應當被加上一個適當的過期時間值。

 

  過期域並不能強制對其進行重新整理或重新載入資源，它只用於快取機制。當對已初始化過的資源發出新請求時，該機制才檢查該資源的過期狀態。

 

  使用者代理通常都有歷史記錄機制，如“後退”按鈕和歷史記錄列表。該種機制可以用來重新顯示某次對話（session）之前已經獲取的實體資訊。在預設狀態下，過期域不對歷史機制使用。除非使用者在使用者代理時指定了對歷史進行過期重新整理，否則，只要實體還儲存著，歷史機制就能顯示它，不論該實體是否已經過期。

 

  注意：應用程式應相容對過期標題或錯誤的實現，如碰到0值或非法的日期格式，應用程式應將其視為“立即過期（expires immediately）”。雖然這些值不符合HTTP/1.0，對於一個健壯的應用來說，還是必要的。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al   Informational  [Page 41]

 

10.8  來自（From）

 

  From請求標題域，如果給出來，則應包括一個使用此使用者代理的人類使用者的Inte　e-地址。該地址應當能被識別，就象822[7]（已經為RFC1123[6]）中的定義一樣。

 

From  = "From" ":" mailbox

 

例如：

 

From: master@w3.org

 

  該標題域可能用來做為登入目的使用，以確定對某資源的請求是否合法。它不應用於不的訪問保護。該域的解釋是，請求已按請求人指定的行為方式完成，而該請求人將為此種方式負責。特殊情況下，機器人（robot）代理也應包括此標題域，域中註明是誰執行它的，這樣，當接收端發生任何問題時，都可以同這個人取得聯絡。

 

  該域中的Internet 地址可以與處理該請求的Internet主機分離。例如，當請求透過代理（）時，應使用原始的傳輸地址。

 

  注意：客戶端在沒有得到使用者批准時，不應傳送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

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 42]

 

  條件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日期，因為該訊息會導致伺服器在未來的某個時間內，用訊息原始的日期對該域值進行再次更新。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 43]

 

10.11  位置（Location）

 

  Location回應標題域定義了由請求URI指定的資源的位置。對於3xx（重定向）回應，位置域必須能幫助伺服器找到相應的URL，以實現對資源的重定向。只允許用絕對URL。

 

Location  = "Location" ":" absoluteURI

 

例如：

 

Location:

 

10.12  註解（Pragma）

 

  Prama普通標題域包括一些可能對請求/回應鏈中的任一接收方有用的特殊指示資訊。從角度看，所有的註解指示了一些特定的可選行為，事實上，一些系統可能會要求行為與指示一致。

 

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

 

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

extension-pragma   = token [ "=" ]

 

  當"no-cache"出現在請求訊息中時，應用程式應當向原始伺服器推送此請求，即使它已經在上次請求時已經快取了一份複製。這樣將保證客戶端能接收到最權威的回應。它也用來在客戶端發現其快取中複製不可用或過期時，對複製進行強制重新整理。

 

  不管註解（Pragma）指示資訊對代理（proxy）及閘道器（gateway）應用程式如何重要，它必須能穿越這些應用，因為該資訊可能對請求/回應鏈上的其它接收方有用。實際上，如果註解與某個接收方無關，它應當被該接收方忽略。

 

10.13 提交方（Referer）

 

  提交方請求標題域是出於伺服器端利益方面的考慮，允許客戶端指明該連結的出處，即該指向資源地址的請求URI是從哪裡獲得的。這樣，伺服器將產生一個連結（back-links）列表，用於維護受歡迎的資源、登入、快取等活動。

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 44]

 

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

 

例子：

 

Referer:

 

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

 

  注意：因為連結的原始碼可能暴露一些隱私資訊，因此強烈建議由使用者來決定是否傳送提交人域。例如，客戶端有個選項可以用來進行離線瀏覽，可以使能或禁止提交人或表單資訊的傳送。

 

10.14  伺服器（Server）

 

  伺服器回應標題域包含由原始伺服器用來處理請求的資訊。該域可包含多個產品標識（3.7節）及註釋以標識伺服器及重要的子產品。按照習慣，產品標識將按其應用的重要順序排列。

 

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

 

例如：

 

Server: CERN/3.0 libwww/2.17

 

如果回應要透過代理來推送，代理應用程式不應將它自己的資料加入產品列表。

 

注意：一些指定伺服器軟體的版本有啟示作用，因為這些版本的軟體存在一些安全，將使伺服器更易受到。提倡伺服器軟體在實現時，將此域變成可以進行配置的選項。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 45]

 

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

 

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）的內容中可能包含用逗號分隔的授權引數列表。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 46]

 

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（相對於被訪問伺服器）聯合使用的realm值（也是大小寫敏感）用來定義保護區域。Realm使得伺服器上的被保護資源被放在特殊的保護分割槽內，這些區域都有各自的授權方案和（或）授權資料庫。Relm值是個字串，通常由原始伺服器來分配，對於授權方案來說，可能存在些附加的語法處理問題。

  通常，使用者代理在收到401（未授權）回應時，可能（也可能不會）希望伺服器對其授權。如果希望授權，使用者代理將在請求中加入授權請求標題（Authorization request-header）域。授權域值由信任證書組成，其中有對使用者代理所請求資源領域的授權資訊。

 

credentials  = basic-credentials

  | ( auth-scheme #auth-param )

 

  可由使用者代理透過信任方式來訪問的區域由保護區域決定。如果早先的請求已經透過認證，在由授權方案，引數和（或）使用者選擇等所指定的時間間隔內，其它的請求可透過相同的信任來訪問該保護區域。

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 47]

 

  除非由授權另行指定，否則單個保護區域的範圍不能擴充套件到伺服器之外。

 

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

 

  的訪問授權不限於這種簡單的質詢回應（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>

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 48]

 

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

 

  如果使用者代理希望傳送使用者標識”Aladdin”和口令“open sesame”，應當遵循下面的標題域形式：

 

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

 

  Basic授權方案是對HTTP伺服器資源的非授權訪問進行過濾的非安全方法。它基於假定客戶端與伺服器端的連線是安全的，為什麼說是假定呢，因為在實際的開放性中，使用basic授權方案往往存在許多不安全的地方。儘管如此，客戶端仍然需要實現此方案，以與採用此種方案的伺服器進行通訊。

 

12.  安全考慮（Security Consrations）

 

  本節的描述對下面各角色有關：資訊應用開發者、資訊提供者、HTTP/1.0中受安全性限制的使用者。本節僅是討論安全問題，並對減少隱患提出了建議，但是並不提供對問題的最終解決辦法。

 

12.1  客戶授權（Authentication of Clients）

 

  正如11.1節中所述，基本授權（Basic authentication）方案不是安全的使用者授權方案，也不能用它來防止實體主體原始碼以文字方式在物理網路中傳輸。HTTP/1.0並不反對在目前日益突出的安全問題面前採用其它的授權方式及加密機制。

 

12.2  安全方法（Safe Methods）

 

  客戶端者應當注意，客戶端軟體代表使用者在Internet上與其它方面互動，並應注意避免讓使用者知道其間發生的具體動作，這些動作可能會暴露對互動各方有重要意義的資訊。

 

  特別情況下，按協定來看，GET和HEAD方法應被視作是安全的，同重新獲得資料應當沒有什麼不同。這就允許使用者代理採用其它方法，如POST，在某種情況下，可能存在這樣一種情況，即請求中包含不安全的行為。

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 49]

 

  通常，伺服器端在執行過GET請求之後，其結果之類的副產品還殘留在伺服器上；實際上，一些動態資源需要這種特性來實現。這裡的重要區別在於使用者沒有請求這些副產品，因而也不應當對這類請求進行解釋。

 

12.3  伺服器日誌資訊的弊端（Abuse of Server Log Information）

 

  伺服器為儲存與使用者請求相關的個人資料，如閱讀方式或感興趣的主題等提供了空間。這些資訊顯然是受某些國家法律保護的，所以對此類資料的處理應當小心。用HTTP協議提供資料的一方應當負責保證這些資訊在未得各方許可之前不會散佈出去。

 

12.4  敏感資訊傳輸（Traner of Sensitive Information）

 

  與其它協議一樣，HTTP協議不能調整傳輸資料的內容，也不存在未卜先知的方法，透過給定請求的上下文資訊片段就能推測出資訊的敏感程度。因而，應用程式應當儘可能像資訊提供方一樣，為該資訊提供更多的控制。在此，有三個標題域值得一提：服務端（Server）、提交方（Referer）和來自（From）。

 

  一些指定伺服器軟體的版本有啟示作用，因為這些版本的軟體存在一些安全漏洞，將使伺服器更易受到攻擊。提倡伺服器軟體在實現時，將Server標題域變成可以進行配置的選項。

 

  提交方（Referer）標題域允許閱讀方式（reading patterns）被暴露，並可匯出反向連結。雖然該域很有用，但是如果包含在此域的使用者資訊如果沒有被分開，則它的作用很可能被濫用。另外，即使此域中使用者資訊被清除，從該域的其它資訊仍可推測出其私有檔案的URI，這可能是該資訊釋出者所不想看到的。

 

  來自（From）標題域可能包括一些與使用者私人隱私及站點安全相關的資訊，因而，在傳送資料前，應當允許使用者使用一些設定手段，如禁止（disable）、允許（enable）、及修改（modify），對此域資訊進行配置。使用者應當能夠根據他們的選擇或使用應用程式提供的預設配置來設定此域的內容。

 

  我們建議，但不做要求：為使用者提供方便的介面來允許（enable）或禁止（disable）傳送From域或Referer域的資訊。

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 50]