讀者定位為具有Java和Web開發經驗的開發和設計人員。

讀者可以學習到關于Cookie的工作原理和Cookie協議的細節，以及在一個HTTP應用代理的場景下Cookie的管理和處理思想，并可以直接使用文中的代碼和思路，提高工作效率。

隨著越來越多的系統移植到了Web上，HTTP協議具有了比以前更廣泛的應用。不同的系統對WEB實現提出了不同的要求，基于HTTP協議的網絡應 用正趨于復雜化和多元化。很多應用需要把用戶請求的頁面進行處理后再返回給用戶，比如頁面關鍵字過濾，頁面內容緩存、內容搜索、頁面翻譯等等。這些應用在 實際效果上類似于一個HTTP應用代理：它們首先接受用戶的請求，根據用戶請求的URL去真正的目標服務器取回目標頁面，再根據不同應用的要求做出相應處 理后返回給用戶。這樣用戶直接面對的就是這個HTTP應用代理，而通過它與其他頁面進行交互。Cookie或Session技術的應用，解決了HTTP協 議的一個問題 -- 無法保持客戶狀態，因此它現在被廣泛應用于各種Web站點中。上面提到的那些應用如果不能處理好Cookie和Session的傳遞、更新和廢除等問題， 就會極大的限制它們所能處理站點的范圍，因此如何在HTTP應用代理中正確處理Cookie，成為一個必須解決的問題。本文結合在頁面翻譯 （Machine Translation System）項目中對于Cookie的處理方法，探討一下這方面的解決方案。

MTS項目簡介及討論前提

Machine Translation System（以下簡稱MTS）是一個在線實時頁面翻譯系統，為用戶在線提供把英文頁面翻譯成其他9種語言的服務。用戶通過向MTS系統提交一個類似下面 的URL使用此服務，其中參數url指明了用戶所需要翻譯的目標地址，參數language指明了所需翻譯成的目標語言，www.mts.com是假想中 提供MTS服務的站點。

HTTP://www.mts.com/translate?url=http://www.ibm.com/&language=French

一個完整的MTS系統處理過程可以分解成以下幾個步驟：

• 用戶向MTS提交合適的URL。
• MTS在接到用戶的請求后，解析出用戶需要翻譯的目標地址和目標語言，根據用戶請求的目標地址，把請求轉發到目標服務器。
• MTS接受來自目標服務器的應答，包括頁面信息和HTTP頭信息。
• MTS在確定得到正確的目標頁面后，把頁面內容送入WebSphere Translation Server進行翻譯。
• 把翻譯后的頁面連同修改后的HTTP頭信息提交給用戶。

當然，這其中涉及到很多的應用處理。比如與各種HTTP/HTTPS站點建立聯結、根據HTTP頭信息進行頁面跳轉和錯誤處理、為始終保持用戶在翻 譯模式下而對目標的HTML頁面進行分析和修改，根據系統設置對某些DNT（Do Not Translate）的頁面進行過濾和跳轉，當然還有對Cookie的處理等等。其他問題跟這篇文章關聯不大，我們重點討論在這種情況下的Cookie處 理。Cookie跟隨目標服務器的HTTP頭信息被MTS接收到，經過MTS整理之后發給客戶端瀏覽器。MTS在接到下一次用戶對同一個站點的翻譯請求 時，再把從客戶端得到的Cookie發送給目標服務器。

在以上的場景中，MTS充當的作用類似于一種HTTP應用代理服務器，它代替用戶取得目標頁面，并在作出相應處理后再提交給用戶。當然，這種代理服 務器不需要用戶修改瀏覽器的代理服務器參數或者網絡配置，而只是簡單的在瀏覽器的地址欄中輸入一個MTS能夠識別的URL即可。此篇文章也是在這樣一個應 用場景的基礎上，展開對HTTP應用代理服務器如何處理Cookie的討論。

?

問題的產生

在MTS系統中，目標服務器的Cookie在兩個地方會產生問題。當MTS接收目標服務器應答的時候，Cookie隨著HTTP頭信息被MTS接收 到的。這時候目標服務器認為MTS就是最終客戶，因此它賦予了Cookie與目標服務器相符的屬性。而如果MTS把這些Cookie原封不動的保存在 HTTP頭信息中，傳給真正的最終用戶的話，用戶的瀏覽器會因為這些Cookie不合法而忽略它們。同理，當Cookie從瀏覽器端傳回目標服務器的時 候，也會遇到相同的問題。因此有必要對Cookie進行一些處理，以保證用戶的瀏覽器能真正識別和利用這些Cookie。

但是為何用戶瀏覽器無法識別從目標服務器傳過來的原始Cookie呢？這是因為出于安全性的考慮，Cookie規范制定的時候對Cookie的產生 和接受設置了一些嚴格的規范，不符合這些規范的Cookie，瀏覽器和服務器都將予以忽略。下面我們從Cookie規范入手進行介紹。

Cookie的規范介紹

目前有以下幾種Cookie規范：

• Netscape cookie草案：是最早的cookie規范，基于rfc2109。盡管這個規范與rc2109有較大的差別，但是很多服務器都與之兼容。
• rfc2109， 是w3c發布的第一個官方cookie規范。理論上講，所有的服務器在處理cookie(版本1)時，都要遵循此規范。遺憾的是，這個規范太嚴格了，以致很多服務器不正確的實施了該規范或仍在使用Netscape規范。
• rfc2965規范定義了cookie版本2，并說明了cookie版本1的不足。

rfc2965規范的使用，目前并不多。rfc2109規范相應要嚴格得多，在實際應用上，并不是所有的瀏覽器和Web服務器都嚴格遵守。因此相比 較而言，Netscape cookie草案倒是一個比較簡潔和被廣泛支持的Cookie規范，因此我們在這里以Netscape cookie草案為基礎進行討論，對于其他兩種規范，我們的討論和代碼具有相同的意義。關于Netscape cookie草案的細節，大家可以參照Netscape官方站點，這里我們列舉一些和我們討論有關的內容。

根據Netscape cookie草案的描述，Cookie 是Web 服務器向用戶的瀏覽器發送的一段ASCII碼文本。一旦收到Cookie，瀏覽器會把Cookie的信息片斷以"名/值"對(name-value pairs)的形式儲存保存在本地。這以后，每當向同一個Web 服務器請求一個新的文檔時，Web 瀏覽器都會發送之站點以前存儲在本地的Cookie。創建Cookie的最初目的是想讓Web服務器能夠通過多個HTTP請求追蹤客戶。有些復雜的網絡應 用需要在不同的網頁之間保持一致，它們需要這種會話狀態的保持能力。

瀏覽器與Web服務器通過HTTP協議進行通訊，而Cookie就是保存在HTTP協議的請求或者應答頭部（在HTTP協議中，數據包括兩部分，一 部分是頭部，由一些名值對構成，用來描述要被傳輸數據的一些信息。一部分是主體(body)，是真正的數據（如HTML頁面等））進行傳送的。

在HTML文檔被發送之前，Web服務器通過傳送HTTP 包頭中的Set-Cookie 消息把一個cookie 發送到用戶的瀏覽器中。下面是一個遵循Netscape cookie草案的完整的Set-Cookie 頭：

Set-Cookie的每個屬性解釋如下：

• Customer=huangxp 一個"名稱＝值"對，把名稱customer設置為值"huangxp"，這個屬性在Cookie中必須有。
• path=/foo 控制哪些訪問能夠觸發cookie 的發送。如果沒有指定path，cookie 會在所有對此站點的HTTP 傳送時發送。如果path=/directory，只有訪問/directory 下面的網頁時，cookie才被發送。在這個例子中，用戶在訪問目錄/foo下的內容時，瀏覽器將發送此cookie。如果指定了path，但是path 與當前訪問的url不符，則此cookie將被忽略。
• domain=.ibm.com 指定cookie被發送到哪臺計算機上。正常情況下，cookie只被送回最初向用戶發送cookie 的計算機。在這個例子中，cookie 會被發送到任何在.ibm.com域中的主機。如果domain 被設為空，domain 就被設置為和提供cookie 的Web 服務器相同。如果domain不為空，并且它的值又和提供cookie的Web服務器域名不符，這個Cookie將被忽略。
• expires= Wednesday, 19-OCT-05 23:12:40 GMT 指定cookie 失效的時間。如果沒有指定失效時間，這個cookie 就不會被寫入計算機的硬盤上，并且只持續到這次會話結束。
• secure 如果secure 這個詞被作為Set-Cookie 頭的一部分，那么cookie 只能通過安全通道傳輸（目前即SSL通道）。否則，瀏覽器將忽略此Cookie。

一旦瀏覽器接收了cookie，這個cookie和對遠端Web服務器的連續請求將一起被瀏覽器發送。例如 前一個cookie 被存入瀏覽器并且瀏覽器試圖請求 URL http://www.ibm.com/foo/index.html 時，下面的HTTP 包頭就被發送到遠端的Web服務器。

GET /foo/index.html HTTP/1.0
Cookie：customer=huangxp

一次典型的網絡瀏覽過程

在了解了Cookie協議的一些基本內容之后，讓我們看看一次典型的網絡瀏覽過程中瀏覽器如何識別和處理Cookie：

• 瀏覽器對于Web服務器應答包頭中Cookie的操作步驟：
  1. 從Web服務器的應答包頭中提取所有的cookie。
  2. 解析這些cookie的組成部分（名稱，值，路徑等等）。
  3. 判定主機是否允許設置這些cookie。允許的話，則把這些Cookie存儲在本地。
• 瀏覽器對Web服務器請求包頭中所有的Cookie進行篩選的步驟：
  1. 根據請求的URL和本地存儲cookie的屬性，判斷那些Cookie能被發送給Web服務器。
  2. 對于多個cookie，判定發送的順序。
  3. 把需要發送的Cookie加入到請求HTTP包頭中一起發送。

由MTS代理的網絡瀏覽過程

以上我們了解了在一個典型的瀏覽器與Web服務器交互的時候，Cookie的傳遞過程。下面我們將看到，如果在MTS代理網絡瀏覽的過程中，不對Cookie進行修改，上面的Cookie傳遞過程將無法實現。

1. 假設用戶希望把 http://www.ibm.com/foo/index.html 頁面翻譯成法文，應該使用如下的url對MTS發出請求

http://www.mts.com/translate?url=http://www.ibm.com/foo/index.html&language=French

2. MTS接收用戶的請求，連接遠程目標服務器 http://www.ibm.com/foo/index.html。目標服務器做出應答，返回HTTP頭和HTML頁面內容。其中，典型的HTTP頭內容如下：

3. MTS不對Set-Cookie后的內容作任何處理，直接把它加到用戶瀏覽器的應答頭上發送給瀏覽器。

4. 瀏覽器將從Set-Cookie中解析出domain和path的值，分別是.ibm.com和/foo，并與請求的url：http: //www.mts.com/translate?url=http://www.ibm.com/foo/index.html&language =French進行比較。請求url的domain是www.mts.com，path是/，與Set-Cookie中的屬性不符，所以瀏覽器將忽略此 Cookie。

另外，在瀏覽器發送Cookie的時候也會遇到同樣的問題，同樣如上例，如果瀏覽器里本來已經存儲了http: //www.ibm.com/foo/的Cookie，但由于用戶要通過MTS訪問此站點，瀏覽器經不會把已經存儲的Cookie上轉到MTS中，MTS 也就無法把之傳遞到http://ibm.com/foo/上。

基于上面Cookie規范的介紹和例證，我們能看出，瀏覽器在接受某一個站點的Cookie的時候，需要檢查Cookie的參數domain、 path、secure，看是否與當前的站點和URL相符，如果不符的話，就會忽略。另一方面。瀏覽器在上傳Cookie的時候，也會根據當前所訪問站點 的屬性，上傳相關的Cookie，而其他的Cookie則不予上傳。

至此，我們討論了需要修改Cookie的根本原因在于Cookie規范的限制。下面我們討論兩種解決問題的思路。