我們正在將ASP站點轉換爲ASP.Net,並遇到重定向和資源位置問題。我們的問題來自於我們設置的特殊性。ASP.Net相對重定向和資源路徑
通過URL- 直接:我們的網站可以通過兩種方式來訪問http://www.mysite.com - 在這種情況下,一切工作正常
- 通過代理服務器通過URL:http://www.proxy.com/mysite_proxy/proxy/
在#2「 mysite_proxy「是proxy.com上的一個映射,它將請求引導到www.mysite.com後面,」proxy「是一個虛擬子網站,它只是將請求重定向到www.mysite.com的根目錄。這實際上意味着給我們一個方便的方法來知道請求是否從代理訪問網站。
我們正在運行到兩個問題與此設置:
- 使用的Response.Redirect或者與「〜」或純相對路徑(Default.aspx的)產生具有的「位置302響應/代理/ rest_of_the_path.aspx「。這會導致瀏覽器請求http://www.proxy.com/proxy/rest_of_the_path.aspx這不是任何東西,甚至不會觸及我們的服務器,因此我們無法在重寫後重新進行操作。
- 在鏈接,圖像,樣式表等頁面中使用基於「〜」的URL創建相同類型的路徑:「/proxy/path_to_resources.css」。我們或許可以通過對所有這些資源使用相對路徑來解決其中的一些問題,雖然這將是很多工作,並且它無法解決由框架和第三方組件產生的類似資源鏈接。
理想情況下,我想找到一個全局修復程序,這將使這些問題對在該網站上工作的開發人員透明。我在這一點上有幾點想法:
- 擺脫代理,它不是真的需要,是出於管理和非技術原因。在技術上最容易完成,在現實世界中最難完成。
- 將問題交給運行代理的組,並說這是他們需要修復它的問題。
- 使用響應過濾器在發送給客戶端之前修改原始html。我知道這可以修復我的資源鏈接,但是我不確定這些標題(需要測試它),並且需要解析每個尋找和重新編寫URL的響應時會有性能問題。
所有這些解決方案在我心中都有很大的負面影響,我希望有人可能有另一個想法。那麼有什麼想法?
另外:已經有很多帖子已經處理這個問題的反面:我有一個相對的URL,我怎麼可能絕對,但我沒有遇到任何符合其他方向。
#3看起來不像它可以修改標題值,至少不是它的當前形式。 – lostatredrock