在httpd的反向代理中，ProxyPass 的主要作用就是修改Content-Location和Location的內容。對這兩個首部的含義做一些說明。
內容協商（content negotiation）
為了說明Content-Location的含義，必須先明白http的內容協商機制。
考慮支持多語言的服務器端：一個相同的URL可以返回不同語言版本的文檔， 其實服務器端就是利用內容協商來識別客戶端的，具體可以參見《http權威指南》第17章。 在請求的頭信息中，包含有Accept開頭的內容協商首部，服務器端可以根據這些內容協商首部來判斷出客戶端的需求。 除此之外，服務器端還可以根據諸如User-Agent這種首部信息進行推測，例如老版本的瀏覽器可能不支持JavaScript，如果User-Agent代表老版本的瀏覽器，那么服務器可以向其響應不包含JavaScript的文檔。
在上面的請求頭部中，我們看到了多個內容協商首部。 在Accept-Languoge中我們還發現了q值，這叫做質量值。 考慮這種情況，假如服務器端僅僅擁有中文和英文兩個版本，並沒有日文，但是客戶端卻最希望能請求到日文內容，這樣服務器端就無法提供合適的文檔給它了。 而q值的意義就是讓客戶端可以提供多個候選方案，q值（0.0-1.0）越大表明優先級越高，例如上圖中表明：優先選擇日文，如果沒有日文優先選擇en-US，沒有en-US,那就選擇en。
上面這種內容協商機制叫做服務器端協商。 為了減輕服務器端的壓力，我們可以使用中間代理來代替服務器端來與客戶端協商，這叫做透明協商。 中間代理如果可以代替服務器，那么代理必須有能力可以完全像服務器那樣處理協商邏輯。對於每一種不同的請求服務器端響應的不同版本的文檔，我們可以稱作是一個 變體。 代理需要有能力根據每一個請求的信息，從緩存的副本中選擇 或者 向服務器請求（當副本中沒有對應的時候），得到准確的變體。 從上面服務器端協商的討論中我們知道除了內容協商首部外，服務器能夠根據其他首部（例如user-agent）來識別客戶端，從而響應不同的變體。 為了讓代理具有完全相同的處理協商邏輯的能力，服務器在響應代理的時候，必須告訴代理除了內容協商首部外還根據什么信息處理協商邏輯了，這個首部叫做vary，例如vary：User-Agent。
Content-Location和Content
Content-Location首部表明返回數據的另一種位置。主要的使用場景是用來表明作為內容協商結果響應的資源的URL。
Location和Content-Location是不同的：Location表明重定向的目標（302），而Content-Location表明無需進行進一步的內容協商就可以直接訪問的資源的URL，例如英文環境客戶端發送 url_file_a 可以得到文件fileA,那么假設響應中Content-Location中內容為 url_file_a_en ,則這個url可以直接訪問到對應的那個英文文件，此時其實就不存在內容協商了。 Location是一個與響應相關的頭信息，而Content-Location是與返回的內容主體相關的頭信息。
參考：
《http權威zhinan》 第17章
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Location