超文本傳輸協議(HTTP)狀態管理的應用

本備忘錄的狀態

本文檔描述了Inte.net社區的最通用的實踐（慣例），需要進一步探討和建議
進行完善。本備忘錄的發布沒有限制。


版權公告

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

IESG注解

TheIESG注解這種機制應用于包含.local頂級域名(TLD)在內，在處理主機名稱不含任
何點在內的情況下，如果沒有注冊一個真正的.local頂級域的話，這種機制可能無法動作。

摘要

這種機制在“HTTP狀態管理體制”（RFC-2965）中已經描述了，其原描述文檔（RFC-2109），
能用于許多不同的目標。然而，許多當前的和潛在的對于這個協議的應用存在爭議，因為它
們有重要的用戶隱私和在安全上的牽連。這個備忘錄識別了那些既不被IETF所推薦，或被認
為是有害的和不安全的超文本協議（HTTP）在某些細節上的應用。本備忘錄也附加了一個HTTP
狀態管理協議中未曾包含的考慮安全方面的詳細的文檔。

1、介紹
HTTP狀態管理機制非常有用，但也存在著很大的爭議。它的實用性緣于眾多的HTTP應用
程序可以得益于它能保存HTTP傳輸狀態的能力，而不需對這種狀態在統一資源定位器（URL）
中進行編碼。而對它存在爭議是因為它在成完成任務時的不確定性和較差的兼容性。由于這
些應用導致了大量的公眾的批評因為他們的存在，導致了網上隱私的保密造成了的威脅。
用戶，確實通過漏洞將一些敏感的信息泄漏給第三方，例如一個用戶訪問了某個網站。而
通過漏洞，將該用戶的信息記錄了下來。那兒同時也有其它的HTTP狀態管理的用戶在，這是
不適當的，即使他們沒有對用戶隱私的威脅。

在RFC-2965文檔中已被詳細說明的的HTTP狀態管理協議IETF并不推薦使用，本備忘錄正是
為此對其應用進行識別，HTTP狀態管理協議被認為存在一定的危害性，因此并不被人看好。

本文檔偶爾使用一些用黑體字表示的術語，當下面這些術語如"必須","不必","應當","
不會",和"可以"以黑體出現時，說明使用它們在說明書中有特定的要求，有關這些術語含
義的討論，如"必須","應當",和"可以"，請參閱[RFC-1123]；術語"不必"和"不會"是在
用法上進行了邏輯的擴展。

2、HTTP狀態管理的應用
HTTP狀態管理的目標是基于HTTP的服務建立一個有狀態的可以持續穿過多重HTTP來處理
事務的“對話”。一個單獨的對話可以包括與多重服務器主機進行事務處理。多個客戶在對于
一個特定的用戶的對話數據被其它客戶共享（例如，通過一個文件系統）時，同樣可以被一
個對話所包括。換句話說，對話保留了用戶與一個服務之間的狀態，面不是兩個特定客戶端
之間的狀態。

使用“無屏蔽”的HTTP協議也同樣以相似的性能完成任務，認識這一點很重要。并且/或
者動態的產生HTML，而沒有狀態管理的擴展。例如，狀態信息能夠從服務到用戶通過嵌入到
一個或在HTTP的重定向中顯現的多個統一資源定位器的對話的標示符中，或動態的產生
HTML；并且狀態信息可以從用戶返回到這個服務當這URL出現一個GET或POST請求時。HTML
表格也能用于傳遞從服務到客戶的狀態信息并返回，而不必要讓用戶知道發生了什么。

不管怎樣，HTTP狀態管理工具提供功能的確是比普通的HTTP和HTML增加了更多。在實踐中
這些附加的功能包括：

（1）在兩個用戶之間互換URL，在有狀態的會話中資源的存取，而沒有與其它會話關聯的
狀態信息的泄漏。（例如，“這兒有FooCorp的網絡目錄入口的URL，而你正想要從這家公司
買拖鞋”）
(2) 不用“緩沖猝發”維持會話狀態的能力。那就是，從URL中隔離出會話狀態允許一
個頁面緩沖來維護唯一的一個已命名的資源的副本。如果此狀態在會話細節URL
中維持，緩沖很有可能不得不維持幾個同樣的拷貝。

(3)與其它的維持會話狀態的技術相比，它具有使用最低的服務器配置和最小限度的費用
的優點。

（4）不管是否用戶已經通過一個特定的“主頁”或“入口”進入,都可以在用戶對服務進
行存取的任何時間聯系用戶與會話。


(5)能夠將會話信息保存在一個穩定的存儲容器中，因此一個“會話”能夠穿過客戶的
干擾，以及系統的重新起動和客戶端或系統的崩潰。.

2.1.推薦的應用

當需要穿過多重HTTP處理事務，此時維持用戶與服務之間的狀態使用HTTP狀態的管理是
很合適的。假如：
（1） 用戶知道會話正在維持并且用戶對其表示贊成,

（2） 用戶可以在任何時間刪除與這樣一個會話相關聯的狀態信息，

（3） 通過跟蹤用戶的使用該服務的方法獲取的信息，如果未經用戶的直接允許，是不會透
露給其它的人員的。

（4） 會話信息無法自己獲取敏感信息并且也不能被用于獲取敏感信息，要偷聽者無法從中
得到任何可用信息。

（5） 最后一點很重要因為cookies通常是明文發送的，因此，很容易被偷聽者竊取。

一個推薦的應用的例子就是“購物車”，購物車的存在對于用戶來說是非常清楚和明白的，
用戶可以明確的“清空”他或她的購物車（或者通過請求來清空或購買貨物），因此將導致對
共享狀態的放棄，這項服務不會不經用戶允許，而向第三方公開用戶的購物習慣和瀏覽習慣。
注意HTTP狀態管理協議有效的允許一個服務提供者拒供應服務，或提供一個限制級別的服
務，如果說某個用戶或一個用戶的客戶的維持會話狀態的請求無法兌現。相反的，缺少合法
的禁止，服務也許會拒絕提供服務，或者提供一個限制級的服務，在這些條件下。從一個純
實踐的角度考慮，如果說客戶端不提供此項服務，那么利用HTTP狀態管理設計的服務也許無
法完全的運作。這樣的服務器應當能夠輕松的處理這種情形并向用戶解釋為什么無法享用全
部的服務。


2.2.存在問題的應用

下面有關HTTP狀態管理的應用被認為是不適當的,從反面進行了闡述：

2.2.1.向第三方泄漏的信息

不經用戶的正式同意，HTTP狀態管理一定不要應用于泄漏用戶或有關用戶瀏覽習慣的信
息給第三方，除了該用戶和服務外。
這種用法是禁止的，即使是把用戶的名字或其它的可對其進行標識的標識符泄漏給第三方，
因為此狀態管理機制自己提供了一個可用于編譯有關用戶信息的標識符。

因為這些實際情況使得HTTP狀態管理機制倍受人們的指責，他們傾向于限制HTTP狀態管
理的效果，因此它被認為對于網絡的操作是有害的。

2.2.2.作為鑒定機制使用UseasanAuthenticationMechanism

通常認為HTTP狀態管理機制作為鑒定機制使用是不合適的。HTTP狀態管理并不是專門為
這種應用而設計的，因此它在鑒定認證的保護上的安全措施是缺乏的，不論是協議的說明書
還是對于普遍配置HTTP的客戶或服務器。絕大多數HTTP會話是不加密的，因此“cookies"
可能會因此被泄漏給偷聽者。此外HTTP客戶端和服務器又有這個特點：僅僅經過簡單的甚至
是根本沒有保護就對"cookies"進行明文存儲來防止信息的泄漏。HTTP狀態管理因此應當不
用于鑒定機制來保護信息避免其泄漏給未經授權的第三方，即使是HTTP會話是經過加密的。

對禁止的用于鑒定的HTTP狀態管理既包括使用于保護服務提供的信息又包括有關用戶
交給服務托管的潛在和敏感的信息。例如，如果泄漏一個用戶的名字、地址、電話號碼或賬
單信息給一個擁有先前與該用戶有關系的“cookies”的客戶是不合適的。

同樣的，HTTP狀態管理不應該用于鑒別用戶的請求對于用戶可能會有令人不快的副作用，
除非用戶知道潛在的副作用并明確同意這樣使用。例如，一項允許用戶通過簡單的“點擊”
定購貨物的服務，完全基于用戶存儲的"cookied"，如果“cookies”會泄漏給第三方的話，
可能會導致一系列的麻煩，如用戶對信用卡上的花費產生懷疑的麻煩，并且/或者發來的不是
自己想要的貨物，

一些HTTP狀態管理在用戶鑒定上的應用可能會導致相關的危害，例如，如果唯一的信息可能
是暴露在服務中，那么服務也會因這些信息的暴露，而受到一些小小的危害

3.用戶對于HTTP狀態管理需要考慮的事項

HTTP狀態管理豐存在很大的爭議，這是因為它有潛在危險，不經過用戶的承認和允許，將
用戶瀏覽習慣的信息泄漏給第三方。雖然這只是一種可能，這種協議本身存在問題相對于在
HTTP客戶端的執行出現錯誤而言是一種較小的錯誤（對于基于HTTP服務的提供者而言）來
保護用戶的興趣。


正如上面所暗示的一樣，還有其它的方法來維持會話狀態而可以不用HTTP狀態管理來實
現，因此其它的方法也可以跟蹤到用戶的瀏覽習慣。確實，很難設想HTTP協議或一個HTTP
客戶怎么做才能夠真正的防止服務泄漏用戶的“點擊軌跡”給其它人，如果服務選擇了這么
做的話。必須保護這些信息不被泄漏，這是這類服務的職責。HTTP客戶端的執行存在不能被
保護的特性，盡管他們能夠采取對策使得HTTP狀態管理更難以應用作此類信息泄漏的機制。








不管通過HTTP狀態管理的使用或其它方法的使用能否更容易導致泄漏，通常HTTP客戶都
可以提供更多的保護來防止不適當的跟蹤信息的泄漏，這是一個值的論證的問題。然而，然
然而，有關其它相關的機制就不屬于本備忘錄討論的范圍了。

3.1.HTTP客戶所必需的性能

用戶自己同意使用HTTP狀態管理很可能不同于對于另一方的的服務，依照是否用戶信任
這項服務來適當地使用這些信息并且限制把它泄漏給它方。用戶因此應當能夠在每一服務的
基礎上，對它的客戶能否使用HTTP狀態管理服務的要求進行控制。特別是：

(1)客戶端一定不要響應HTTP狀態管理的請求，除非確實是被客戶激活。

(2)在客戶提供任何狀態信息給服器前，客戶端應該提供一個允許用戶回顧的有效的界
面，并且批準或者拒絕來自服務的任何特定請求以維護狀態信息。

(3)在每一服務的基礎上，一但響應任何特定的來自服務器的請求，在客戶提供任何狀
態信息給服務器之前，客戶端就應當立即提供一個有效的界面，這個界面允許用戶通知他們
的客戶端忽略所有以維持狀態信息的來自特定服務的請求。

(4)客戶應當提供一個有效的界面允許用戶禁止未來對服務進行任何狀信息的傳輸。
或者放棄任何已經保存的對于服務的狀態信息，即使是用戶先前認可的維持狀態信息的服務
請求。

(5)客戶應當提供一個有效的界面，允許用戶去中斷一個先前的請求，而不為已經給
予的服務保持狀態管理信息

3.2.域匹配算法的局限性。

域匹配算法在RFC-2965中第2段中企發性的允許用戶去“猜”是否兩個域是同一個服
務的一部分。關于如何域能被使用的規則很少，并且域名結構和它們如何被從頂級域轉換為
其它域名（也就是客戶不能說出域名的哪一部分被分配給了服務。因此，沒有字符串比較算
法（包括域名匹配算法）可以從一個屬于其他部分的域名中用來區分屬于特別服務的域名。

作為上面的說明，每一項服務最終應負責的是負保證用戶的信息不會不適當的泄露給第三方。
通過仔細地選擇域名，或第三方通過維持給主機指定域名，利用狀態管理泄露信息給第三方，
至少通過使用其他方法在信息的泄漏上是一樣的不合適的。

4.安全考慮

整篇備忘錄都是有關安全考慮的。

5.作者的地址

KeithMoore
UniversityofTennesseeComputerScienceDepartment
1122VolunteerBlvd,Suite203
KnoxvilleTN,37996-3450

EMail:moore@cs.utk.edu


NedFreed
InnosoftInternational,Inc.
1050LakesDrive
WestCovina,CA81790

EMail:ned.freed@innosoft.com

6.參考文獻

[RFC1123]Braden,R.,"RequirementsforInternetHosts--
ApplicationandSupport",STD3,RFC1123,October1989.

[RFC2965]Kristol,D.andL.Montulli,"HTTPStateManagement
Mechanism",RFC2965,October2000.

[RFC2109]Kristol,D.andL.Montulli,"HTTPStateManagement
Mechanism",RFC2109,February1997.

7.版權聲明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致謝

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.