記錄 ---- Web代理

Web代理

Web的中間實體

Web代理(Web proxy)服務器是網絡的中間實體。代理位於客戶端和服務器之間，扮演"中間人"的角色，在各端點之間來回傳送HTTP報文。Web上的代理服務器是表明客戶端完成事務處理的中間人。若是沒有Web代理，Web客戶端就要直接與Web服務器進行對話。有了Web代理，客戶端就能夠與代理進行對話，而後由代理表明客戶端與服務器進行交流。客戶端仍然會完成對事務的處理，但它是經過代理服務器提供的優質服務來實現的。HTTP的代理服務器既是Web服務器又是Web客戶端。Web客戶端會向代理髮送請求報文，代理服務器必須像Web服務器同樣，正確地處理請求和鏈接，而後返回響應。同時，代理自身要向服務器發送請求，這樣，其行爲就必須像正確的Web客戶端同樣，要發送請求並接收響應。若是要建立本身的Web代理，就要認真地遵循爲Web客戶端和Web服務器制定的規則。

• 對於Web客戶端來講：代理扮演的是Web服務器的角色，接受請求報文，返回響應報文；
• 對於Web服務器來講：代理扮演的是Web客戶端的角色，發送請求報文，接收響應報文。

代理服務器能夠是某個客戶端專用的，也能夠是不少客戶端共享的。單個客戶端專用的代理被稱爲私有代理。衆多客戶端共享的代理被稱爲公共代理。

• 公共代理：大多數代理都是公共的共享代理。集中式代理的成本效率更高，更容易管理。某些代理應用，好比高速緩存代理服務器，會利用用戶間共同的請求，這樣的話，匯入同一個代理服務器的用戶越多，它就越有用。
• 私有代理：專用的私有代理並不常見，但它們確實存在，尤爲是直接運行在客戶端計算機上的時候。有些瀏覽器輔助產品，以及一些ISP服務，會在用戶的PC上直接運行一些小型的代理，以便擴展瀏覽器特性，提升性能，或爲免費ISP服務提供主機廣告。

代理與網關

嚴格來講，代理鏈接的是兩個或多個使用相同協議的應用程序，而網關鏈接的則是兩個或多個使用不一樣協議的端點。網關扮演的是"協議轉換器"的角色，即便客戶端和服務器使用的是不一樣的協議，客戶端也能夠經過它完成與服務器之間的事務處理。實際上，代理和網關之間的區別很模糊。因爲瀏覽器和服務器實現的是不一樣版本的HTTP，代理也常常要作一些協議轉換工做。而商業化的代理服務器也會實現網關的功能來支持SSL安全協議、SOCKS防火牆、FTP訪問，以及基於Web的應用程序。

代理的功能

代理服務器能夠實現各類時髦且有用的功能。它們能夠改善安全性，提升性能，節省費用。代理服務器能夠看到並接觸到全部流過的HTTP流量，因此代理能夠監視流量並對其進行修改，以實現不少有用的增值Web服務。

• 訪問控制：能夠用代理服務器在大量Web服務器和Web資源之間實現統一的訪問控制策略，建立審覈跟蹤機制。這在大型企業環境或其餘分佈式機構中是頗有用的。在集中式代理服務器上能夠對全部訪問控制功能進行配置，而無需在衆多由不一樣組織管理、不一樣廠商製造、使用不一樣模式的Web服務器上進行常常性的訪問控制升級。
• 安全防火牆：網絡安全工程師一般會使用代理服務器來提升安全性。代理服務器會在網絡中的單一安全節點上限制哪些應用層協議的數據能夠流入或流出一個組織。還能夠提供用來消除病毒的Web和E-mail代理使用的那種掛鉤程序，以便對流量進行詳細的檢查。
• Web緩存：代理緩存維護了經常使用文檔的本地副本，並將它們按需提供，以減小緩慢且昂貴的因特網通訊。
• 反向代理：代理能夠假扮Web服務器。這些被稱爲反向代理(reverse proxy)的代理接收發給Web服務器的真實請求，但與Web服務器不一樣的是，它們能夠發起與其餘服務器的通訊，以便按需定位所請求的內容。能夠用這些反向代理來提升訪問慢速Web服務器上公共內容時的性能。在這種配置中，一般將這些反向代理稱爲服務器加速器(server accelerator)。還能夠將反向代理與內容路由功能配合使用，以建立按需複製內容的分佈式網絡。
• 內容路由器：代理服務器能夠做爲"內容路由器"使用，根據因特網流量情況以及內容類型將請求導向特定的Web服務器。內容路由器也能夠用來實現各類服務級的請求。好比，若是用戶或內容提供者付費要求提供更高的性能，內容路由器能夠將請求轉發到附近的複製緩存，或者若是用戶申請了過濾服務，還能夠經過過濾代理來轉發HTTP請求。能夠用自適應內容路由代理來構建不少有趣的服務。
• 轉碼器：代理服務器在將內容發送給客戶端以前，能夠修改內容的主體格式。在這些數據表示法之間進行的透明轉換被稱爲轉碼(transcoding)。轉碼代理能夠在傳輸GIF圖片時，將其轉換成JPEG圖片，以減少尺寸。也能夠對圖片進行壓縮，或下降顏色的色彩飽和度以便在電視上觀看。一樣，能夠對文本文件進行壓縮，併爲可以使用因特網的呼機和智能手機生成小型的文本摘要Web頁面。代理甚至能夠在傳輸文檔的過程當中將其轉換成外語。

• 匿名者：匿名者代理會主動從HTTP報文中刪除身份特性(好比客戶端IP地址、From首部、Referer首部、cookie、URI的會話 ID)，從而提供高度的私密性和匿名性。

  • 從User-Agent首部刪除用戶的計算機與OS類型。
  • 刪除From首部以保護用戶的E-mail地址。
  • 刪除Referer首部來掩蓋用戶訪問過的其餘站點。
  • 刪除Cookie首部以剔除概要信息和身份的數據。

代理會作些什麼

代理服務器的部署位置

能夠根據其目標用途，將代理放在任意位置。

• 出口代理：能夠將代理固定在本地網絡的出口點，以便控制本地網絡與大型因特網之間的流量。能夠在公司網絡中使用出口代理，提供針對公司外部惡意黑客的防火牆保護，或下降帶寬費用，提升因特網流量的性能。
• 訪問(入口)代理：代理常被放在ISP訪問點上，用以處理來自客戶的聚合請求。ISP使用緩存代理來存儲經常使用文檔的副本，以提升用戶(尤爲是高速鏈接用戶)的下載速度，下降因特網帶寬耗費。
• 反向代理：代理一般會被部署在網絡邊緣，在Web服務器以前，做爲反向代理使用，在那裏它們能夠處理全部傳送給Web服務器的請求，並只在必要時向Web服務器請求資源。反向代理能夠提升Web服務器的安全特性，或者將快速的Web服務器緩存放在較慢的服務器以前，以提升性能。反向代理一般會直接冒用Web服務器的名字和IP地址，這樣全部的請求就會被髮送給代理而不是服務器了。
• 網絡交換代理：能夠將具備足夠處理能力的代理放在網絡之間的因特網對等交換點上，經過緩存來減輕因特網節點的擁塞，並對流量進行監視。

代理的層次結構

能夠經過代理層次結構(proxy hierarchy)將代理級聯起來。在代理的層次結構中，會將報文從一個代理傳給另外一個代理，直到最終抵達原始服務器爲止(而後經過代理傳回給客戶端)。代理層次結構中的代理服務器被賦予了父(parent)和子(child)的關係。下一個入口(inbound)代理(靠近服務器)被稱爲父代理，下一個出口(outbound)代理(靠近客戶端)被稱爲子代理。

代理服務器能夠根據衆多因素，將報文轉發給一個不斷變化的代理服務器和原始服務器集。訪問代理會根據不一樣的狀況將報文轉發給父代理或原始服務器。

• 負載均衡：子代理可能會根據當前父代理上的工做負載級別來決定如何選擇一個父代理，以均衡負載。
• 地理位置附近的路由：子代理可能會選擇負責原始服務器所在物理區域的父代理。
• 協議/類型路由：子代理可能會根據URI將報文轉發到不一樣的父代理和原始服務器上去。某些特定類型的URI可能要經過一些特殊的代理服務器轉發請求，以便進行特殊的協議處理。
• 基於訂購的路由：若是發佈者爲高性能服務額外付費了，它們的URI就會被轉發到大型緩存或壓縮引擎上去，以提升性能。在不一樣的產品中，動態父路由邏輯的實現方式各有不一樣，包括使用配置文件、腳本語言和動態可執行插件等。

代理是如何獲取流量的

客戶端一般會直接與Web服務器進行通訊，有四種常見方式可使客戶端流量流向代理。

• 修改客戶端：不少Web客戶端，都支持手工和自動的代理配置。若是將客戶端配置爲使用代理服務器，客戶端就會將HTTP請求有意地直接發送給代理，而不是原始服務器。
• 修改網絡：網絡基礎設施能夠經過若干種技術手段，在客戶端不知道，或沒有參與的狀況下，攔截網絡流量並將其導入代理。這種攔截一般都依賴於監視HTTP流量的交換設備及路由設備，在客戶端絕不知情的狀況下，對其進行攔截，並將流量導入一個代理。這種代理被稱爲攔截(intercepting)代理。
• 修改DNS的命名空間：放在Web服務器以前的代理服務器——反向代理，會直接假扮Web服務器的名字和IP地址，這樣，全部的請求就會發送給這些反向代理，而不是服務器了。要實現這一點，能夠手工編輯DNS名稱列表，或者用特殊的動態DNS服務器根據須要來肯定適當的代理或服務器。有時在安裝過程當中，真實服務器的IP地址和名稱被修改了，反向代理獲得的會是以前的地址和名稱。
• 修改Web服務器：也能夠將某些Web服務器配置爲向客戶端發送一條HTTP重定向命令(響應碼305)，將客戶端請求重定向到一個代理上去。收到重定向命令後，客戶端會與代理進行通訊。

客戶端的代理設置

全部現代的Web瀏覽器都容許用戶對代理的使用進行配置。實際上，不少瀏覽器都提供了多種配置代理的方式，其中包括如下幾種。

• 手工配置：顯式地設置要使用的代理。
• 預先配置瀏覽器：瀏覽器廠商或發行商會在將瀏覽器發送給其客戶以前預先對瀏覽器(或全部其餘Web客戶端)的代理設置進行手工配置。手工代理配置很簡單但有些死板。只能爲全部內容指定惟一的一個代理服務器，並且不支持故障轉移。手工代理配置還會給大型組織帶來管理問題。若是配置過的瀏覽器基數很大，那麼須要進行修改的時候，從新配置每一個瀏覽器是很是困難，甚至是不可能的。
• 代理的自動配置(Proxy Auto-Configuration，PAC)：提供一個URI，指向一個用JavaScript語言編寫的代理自動配置文件；客戶端會取回這個JavaScript文件，並運行它以決定是否應該使用一個代理，若是是的話，應該使用哪一個代理服務器。
• WPAD的代理髮現：有些瀏覽器支持Web代理自動發現協議(Web Proxy Autodiscovery Protocol，WPAD)，這個協議會自動檢測出瀏覽器能夠從哪一個"配置服務器"下載到一個自動配置文件。WPAD協議的算法會使用發現機制的逐級上升策略自動地爲瀏覽器查找合適的PAC文件。WPAD會使用一系列的資源發現技術來斷定適當的PAC文件。並非全部組織都可以使用全部的發現技術，因此WPAD使用了不少種發現技術。WPAD會一個接一個地對每種技術進行嘗試，直到成功爲止。

PAC文件是一些小型的JavaScript程序，能夠在運行過程當中計算代理設置，所以，是一種更動態的代理配置解決方案。訪問每一個文檔時，JavaScript函數都會選擇恰當的代理服務器。要使用PAC文件，就要用JavaScript PAC文件的URI來配置瀏覽器[配置方式與手工配置相似，但要在"automatic configuration"(自動配置)框中提供一個URI]。瀏覽器會從這個URI上獲取PAC文件，並用JavaScript邏輯爲每次訪問計算恰當的代理服務器。PAC文件的後綴一般是".pac"，MIME類型一般是"application/x-ns- proxy-autoconfig"。每一個PAC文件都必須定義一個名爲"FindProxyForURL(url,host)"的函數，用來計算訪問URI時使用的適當的代理服務器。

代理自動配置腳本的返回值：

"FindProxyForURL(url,host)"的返回值	描述
DIRECT	不通過任何代理，直接進行鏈接
PROXY host:port	應該使用指定的代理
SOCKS host:port	應該使用指定的SOCKS服務器

實現 WPAD 協議的客戶端須要：

• 用WPAD找到PAC的URI；
• 從指定的URI獲取PAC文件；
• 執行PAC文件來斷定代理服務器；
• 爲請求使用代理服務器。

當前的 WPAD 協議規範按順序定義了下列技術：

• 動態主機配置協議(DHCP)；
• 服務定位協議(Service Location Protocol，SLP)；
• DNS知名主機名；
• DNS SRV記錄；
• TXT記錄中的DNS服務URI。

代理請求

代理URI與服務器URI的不一樣

除了一點以外，Web服務器報文和Web代理報文的語法是同樣的。客戶端向服務器而不是代理髮送請求時，HTTP請求報文中的URI會有所不一樣。客戶端向Web服務器發送請求時，請求行中只包含部分URI(沒有方案、主機或端口)。但當客戶端向代理髮送請求時，請求行中則包含完整的URI。</p>
<p>爲何會有兩種不一樣的請求格式，一種用於代理，另外一種用於服務器呢？在原始的HTTP設計中，客戶端會直接與單個服務器進行對話。不存在虛擬主機，也沒有爲代理制定什麼規則。單個的服務器都知道本身的主機名和端口，因此，爲了不發送冗餘信息，客戶端只需發送部分URI便可，無需發送方案和主機(以及端口)。代理出現以後，使用部分URI就有問題了。代理須要知道目標服務器的名稱，這樣它們才能創建本身與服務器的鏈接。基於代理的網關要知道URI的方案才能鏈接到FTP資源和其餘方案上去。"HTTP/1.0"要求代理請求發送完整的URI，解決了這個問題，但它爲服務器請求保留部分URI的形式(已經有至關多的服務器都改成支持完整URI了)。所以，咱們要將部分URI發送給服務器，將完整URI發送給代理。在顯式地配置客戶端代理設置的狀況下，客戶端就知道要發佈哪一種類型的請求了。

代理"缺乏方案/主機/端口"的問題與虛擬主機Web服務器面臨的問題相同。虛擬主機Web服務器會在不少Web站點間共享同一個物理Web服務器。包含部分URI的請求到達時，虛擬主機Web服務器須要知道目的Web站點的主機名。

儘管它們出現的問題類似，但解決方法卻有所不一樣：

• 顯式的代理要求在請求報文中使用完整URI來解決這個問題；
• 虛擬主機 Web 服務器要求使用Host首部來承載主機和端口信息。

攔截代理會收到部分URI

只要客戶端正確地實現了HTTP，它們就會在請求中包含完整的URI，發送給通過顯式配置的代理。這樣解決了部分問題，但還有一個問題：客戶端並不老是知道它是在和代理進行對話，由於有些代理對客戶端多是不可見的。即便沒有將客戶端配置爲使用代理，客戶端的流量也可能會通過替代物或攔截代理。在這兩種狀況下，客戶端都會認爲它在與Web服務器進行對話，不會發送完整的URI。

• 反向代理是一個用來取代原始服務器的代理服務器，它一般會經過假扮服務器的主機名或IP地址來作到這一點。它會收到Web服務器請求，可能會向真正的服務器提供緩存的響應或者代理請求。客戶端沒法區分反向代理和Web服務器，所以它會發送部分URI。
• 攔截代理是網絡流量中的代理服務器，它會攔截從客戶端發往服務器的請求，並提供一個緩存響應，或對其進行轉發。因爲攔截代理攔截了從客戶端到服務器的流量，因此它會收到發送給Web服務器的部分URI。

處理服務器請求

因爲將流量重定向到代理服務器的方式有所不一樣，通用的代理服務器既應該支持請求報文中的完整URI，也應該支持部分URI。若是是顯式的代理請求，代理就應該使用完整URI，若是是Web服務器請求，就應該使用部分URI和虛擬Host首部。

使用完整和部分URI的規則以下所示。

• 若是提供的是完整URI，代理就應該使用這個完整URI；
• 若是提供的是部分URI，並且有Host首部，就應該用Host首部來肯定原始服務器的名字和端口號；

• 若是提供的是部分URI，並且沒有Host首部，就要用其餘方法來肯定原始服務器：

  • 若是代理是表明原始服務器的替代物，能夠用真實服務器的地址和端口號來配置代理；
  • 若是流量被攔截了，並且攔截者也能夠提供原始的IP地址和端口，代理就可使用攔截技術提供的IP地址和端口號；
  • 若是全部方法都失敗了，代理沒有足夠的信息來肯定原始服務器，就必須返回一條錯誤報文(一般是建議用戶升級到支持Host首部的現代瀏覽器)。

修改URI的規則

代理服務器要在轉發報文時修改請求URI的話，須要特別當心。對URI的微小修改，甚至是看起來無害的修改，均可能給下游服務器帶來一些互操做性問題。尤爲是，如今已知有些代理會在將URI轉發給下一跳節點以前將URI"規範"爲標準格式。有些看起來無害的轉換行爲，好比用顯式的":80"來取代默認的HTTP端口，或者用適當的換碼轉義符來取代非法的保留字符以校訂URI，就可能形成互操做性問題。總之，代理服務器要儘可能寬容一些。它們的目標不是成爲強制實現嚴格協議一致性的"協議警察"，由於這樣可能會嚴重破壞以前能正常工做的服務。特別是，HTTP規範禁止通常的攔截代理在轉發URI時重寫其絕對路徑部分。惟一的例外是能夠用"/"來取代空路徑。

URI的客戶端自動擴展和主機名解析

根據是否有代理，瀏覽器對請求URI的解析會有所不一樣。沒有代理時，瀏覽器會獲取你輸入的URI，嘗試着尋找相應的IP地址。若是找到了主機名，瀏覽器會嘗試相應的IP地址直到得到成功的鏈接爲止。可是，若是沒有找到主機，不少瀏覽器都會嘗試着提供某種主機名自動「擴展」機制，以防用戶輸入的是主機「簡短」的縮寫形式。

• 不少瀏覽器會嘗試着加入前綴"www."和後綴".com"，以防用戶只輸入了常見Web站點名的中間部分。
• 有些瀏覽器甚至會將未解析出來的URI傳遞給第三方站點，這個站點會嘗試着校訂拼寫錯誤，並給出一些用戶可能但願訪問的URI建議。
• 並且，大多數系統中的DNS配置容許用戶只輸入主機名的前綴，而後DNS會自動搜索域名。

追蹤報文

如今，在將Web請求從客戶端傳送到服務器的路徑上，通過兩個或多個代理是很常見的。好比，出於安全和節省費用的考慮，不少公司都會用緩存代理服務器來訪問因特網，並且不少大型ISP都會使用代理緩存來提升性能並實現各類特性。如今，有至關比例的Web請求都是經過代理轉發的。同時，出於性能緣由，把內容複製到遍及全球的替代物緩存庫中的情形也愈來愈常見了。代理是由不一樣廠商開發的。它們有不一樣的特性和缺陷，由各類不一樣的組織負責管理。隨着代理的逐漸流行，咱們要可以追蹤通過代理的報文流，以檢測出各類問題，其重要性就跟追蹤通過不一樣交換機和路由器傳輸的IP分組流同樣。

Via首部

Via首部字段列出了與報文途經的每一箇中間節點(代理或網關)有關的信息。報文每通過一個節點，都必須將這個中間節點添加到Via列表的末尾。Via首部字段用於記錄報文的轉發，診斷報文循環，標識請求/響應鏈上全部發送者的協議能力。代理也能夠用Via首部來檢測網絡中的路由循環。代理應該在發送一條請求以前，在Via首部插入一個與其自身有關的獨特字符串，並在輸入的請求中查找這個字符串，以檢測網絡中是否存在路由循環。

• Via的語法：Via首部字段包含一個由逗號分隔的路標(waypoint)。每一個路標都表示一個獨立的代理服務器或網關，且包含與那個中間節點的協議和地址有關的信息。
  每一個Via路標中最多包含4個組件：一個可選的協議名(默認爲HTTP)、一個必選的協議版本、一個必選的節點名和一個可選的描述性註釋。

  • 協議名：中間節點收到的協議。若是協議爲HTTP的話，協議名就是可選的。不然，要在版本以前加上協議名，中間用"/"分隔。網關將HTTP請求鏈接到其餘協議(HTTPS、FTP等)時，可能會使用非HTTP協議。
  • 協議版本：所收到的報文版本。版本的格式與協議有關。HTTP使用的是標準版本號(1.0、1.1等)。版本包含在Via字段中，這樣，以後的應用程序就會知道前面全部中間節點的協議能力了。
  • 節點名：中間節點的主機和可選端口號(若是沒有包含端口號，能夠假定使用的是協議的默認端口號)。在某些狀況下，出於隱私方面的考慮，某個組織可能不肯意給出真實的主機名，在這種狀況下能夠用一個假名來代替。
  • 節點註釋：進一步描述這個中間節點的可選註釋。一般會在這裏包含廠商和版本信息，有些代理服務器還會在註釋字段中包含一些與此設備上所發生事件有關的診斷信息。
• Via的請求和響應路徑：請求和響應報文都會通過代理進行傳輸，所以，請求和響應報文中都要有Via首部。請求和響應一般都是經過同一條TCP鏈接傳送的，因此響應報文會沿着與請求報文相同的路徑回傳。
• Via與網關：有些代理會爲使用非HTTP協議的服務器提供網關的功能。Via首部記錄了這些協議轉換，這樣，HTTP應用程序就會了解代理鏈上各點的協議處理能力以及所作的協議轉換了。
• Server和Via首部：Server響應首部字段對原始服務器使用的軟件進行了描述。若是響應報文是經過代理轉發的，必定要確保代理沒有修改Server首部。Server首部是用於原始服務器的。代理應該添加的是Via條目。
• Via的隱私和安全問題：有時候，咱們並不但願在Via字符串中使用確切的主機名。總地來講，除非顯式地容許了這種行爲，不然，當代理服務器做爲網絡防火牆的一部分使用時，是不該該轉發防火牆後面那些主機的名字和端口號的，由於防火牆後面的網絡結構信息可能會被惡意羣體利用。若是不容許進行Via節點名轉發，做爲安全防線的一部分使用的代理就應該用適當的假名來取代那臺主機的名字。通常來講，即便隱藏了真實名稱，代理也應該嘗試着爲每臺代理服務器保留一個Via路標條目。對那些有着很是強烈的隱私要求，須要隱藏內部網絡設計和拓撲結構的組織來講，代理應該將一個(接收協議值相同的)有序Via路標條目序列合併成一個聯合條目。除非這些條目都在同一個組織的控制之下，並且已經用假名取代了主機名，不然就不能將其合併起來。一樣，接收協議值不一樣的條目也不能合併起來。

TRACE方法

代理服務器能夠在轉發報文時對其進行修改。能夠添加、修改或刪除首部，也能夠將主體部分轉換成不一樣的格式。代理變得愈來愈複雜，開發代理產品的廠商也愈來愈多，互操做性問題也開始逐漸顯現。爲了便於對代理網絡進行診斷，咱們須要有一種便捷的方式來觀察在經過HTTP代理網絡逐跳轉發報文的過程當中，報文是怎樣變化的。經過"HTTP/1.1"的TRACE方法，用戶能夠跟蹤經代理鏈傳輸的請求報文，觀察報文通過了哪些代理，以及每一個代理是如何對請求報文進行修改的。TRACE對代理流的調試很是有用。當TRACE請求到達目的服務器時，整條請求報文都會被封裝在一條HTTP響應的主體中回送給發送端。當TRACE響應到達時，客戶端能夠檢查服務器收到的確切報文，以及它所通過的代理列表(在Via首部)。TRACE響應的Content-Type爲message/http，狀態爲"200 OK"。</p>
<p>Max-Forwards：一般，無論中間插入了多少代理，TRACE報文都會沿着整條路徑傳到目的服務器上。可使用Max-Forwards(最大轉發次數)首部來限制TRACE和OPTIONS請求所通過的代理跳數，在測試代理鏈是不是在無限循環中轉發報文，或者查看鏈中特定代理服務器的效果時，它是頗有用的。Max-Forwards也能夠限制OPTIONS報文的轉發。Max-Forwards請求首部字段包含了一個整數，用來講明這條請求報文還能夠被轉發的次數。若是Max-Forwards的值爲零(Max-Forwards:0)，那麼即便接收者不是原始服務器，它也必須將TRACE報文回送給客戶端，而不該該繼續轉發。若是收到的Max-Forwards值大於零，轉發的報文中就必須包含一個更新了的Max-Forwards字段，其值會被減一。全部的代理和網關都應該支持Max-Forwards。能夠用Max-Forwards來查看在代理鏈的任意一跳上接收到的請求。

代理認證

代理能夠做爲訪問控制設備使用。HTTP定義了一種名爲代理認證(proxy authentication)的機制，這種機制能夠阻止對內容的請求，直到用戶向代理提供了有效的訪問權限證書爲止。若傳輸鏈路中有多個代理，且每一個代理都要進行認證時，代理認證一般沒法很好地工做。

• 對受限內容的請求到達一臺代理服務器時，代理服務器能夠返回一個要求使用訪問證書的"407 Proxy Authorization Required"狀態碼，以及一個用於描述怎樣提供這些證書的Proxy-Authenticate首部字段。
• 客戶端收到407響應時，會嘗試着從本地數據庫中，或者經過提示用戶來蒐集所須要的證書。
• 只要得到了證書，客戶端就會從新發送請求，在Proxy-Authorization首部字段中提供所要求的證書。
• 若是證書有效，代理就會將原始請求沿着傳輸鏈路向下傳送；不然，就發送另外一條407應答。

代理的互操做性

客戶端、服務器和代理是由不一樣廠商構建的，實現的是不一樣版本的HTTP規範。它們支持的特性各不相同，也存在着不一樣的問題。代理服務器位於客戶端和服務器設備之間，這些設備實現的協議可能有所不一樣，可能存在着很棘手的問題。

處理代理不支持的首部和方法

代理服務器可能沒法理解全部經其傳輸的首部字段。有些首部可能比代理自身還要新；其餘首部多是特定應用程序獨有的定製首部。代理必須對不認識的首部字段進行轉發，並且必須維持同名首部字段的相對順序。相似地，若是代理不熟悉某個方法，那麼只要可能，就應該嘗試着將報文轉發到下一跳節點上去。

OPTIONS：發現對可選特性的支持

經過OPTIONS方法，客戶端(或代理)能夠發現Web服務器或者其上某個特定資源所支持的功能(好比，它們所支持的方法)。經過使用OPTIONS，客戶端能夠在與服務器進行交互以前，肯定服務器的能力，這樣它就能夠更方便地與具有不一樣特性的代理和服務器進行互操做了。若是OPTIONS請求的URI是個"*"(星號)，請求的就是整個服務器所支持的功能。若是URI是個實際資源地址，OPTIONS請求就是在查詢那個特定資源的可用特性。若是成功，OPTIONS方法就會返回一個包含了各類首部字段的"200 OK"響應，這些 字段描述了服務器所支持的，或資源可用的各類可選特性。"HTTP/1.1"在響應中惟一指定的首部字段是Allow首部，這個首部用於描述服務器所支持的各類方法(或者服務器上的特定資源)。OPTIONS容許在可選的響應主體中包含更多的信息，但並無對這種用法進行定義。

Allow 首部

Allow實體首部字段列出了請求URI標識的資源所支持的方法列表，若是請求URI爲"*"(星號)的話，列出的就是整個服務器所支持的方法列表。能夠將Allow首部做爲請求首部，建議在新的資源上支持某些方法。並不要求服務器支持這些方法，但應該在相應的響應中包含一個Allow首部，列出它實際支持的方法。由於客戶端可能已經經過其餘途徑與原始服務器進行了交流，因此即便代理沒法理解指定的全部方法，也不能對Allow首部字段進行修改。