因此，我們有一個非常龐大而複雜的網站，需要將大量狀態信息放入URL中。大多數時候，這只是一個很好的例子，而且應用程序運行良好。但是，URL的長度變得非常長（實際上越來越多）。由於URL長度限制，這在IE中導致了巨大的問題。減少URL大小的方法？
我在想，人們用什麼策略/方法來減少URL的長度？具體來說，我只需要減少URL中的某些參數，可能不是整個事情。
過去，我們已經將一些狀態數據推入會話中...但是這會降低我們應用程序中的可尋址性（這非常重要）。所以，任何可以保持可尋址性的策略都會受到青睞。
謝謝！
編輯：回答一些問題，並澄清一點，我們的大部分參數都沒有......但是他們中的一些有可能會很長的可能性是動態生成的問題。這些參數可以包含URL中任何合法的內容（這意味着它們不只是數字或只是字母，可以是任何東西）。區分大小寫可能會也可能不重要。
此外，理想情況下，我們可以將這些轉換爲POST，但是由於需要進行巨大的體系結構更改，我不認爲這是真的可行。
我們的大多數參數都不是一個問題......但他們中的一些有可能會很長的可能性
我沒有看到一個方法來解決是動態生成的如果您希望在URL中保留完整狀態信息，而無需在會話中存儲數據，或永久在服務器端。
您可能使用某種壓縮算法可以節省幾個字節，但會使URL不可讀，大多數算法對小字符串的效率不高，而壓縮不會產生可預測的結果。
浮現在腦海中唯一的其他想法是
縮短參數名稱（query =>q，page =>p ...如果參數順序是非常靜態的）可能會節省幾個字節
，使用mod_rewritten目錄結構/url/param1/param2/param3可以節省幾個字節，因爲你不需要使用參數名稱
無論數據重複性和可可「縮短」回數字ID或短標識符（如公司分支機構，產品名稱......地名）保持在內部，全球性的，永久性的查找表（London =>1，Paris =>2 ...）
除此之外，我認爲將數據存儲在服務器端，通過隨機密鑰標識爲@Guido已經表明，這是唯一真正的方法。向上的一面是，你有沒有大小限制都：像
example.com/?key=A23H7230sJFC
的URL可以「包含」在服務器端儘可能多的信息，只要你想。
向下的一面，當然，是爲了讓這些URL可靠地工作，你必須保持你的服務器上的數據無限期。這就像有你自己的小URL縮短服務......這是否是一個有吸引力的選擇，將取決於大局。
我覺得那差不多了！
我實際上傾向於壓縮路線...它看起來像使用gZip我可以從1400個字符降到1000 ...我必須運行一些更多的測試，以確保這實際上是值得的。你的其他建議也都非常好。 – Polaris878 2010-09-08 20:16:14
如果您不想將這些數據保存在session範圍內，您可以：
當他們真的是可導航參數時，一個很好的選擇是將這些參數加入URL的第一部分，例如
http://example.site.com/ViewPerson.xx?PersonID=123 => http://example.site.com/View/Person/123/
是的，這是一個非常好的建議......我希望我們可以在此基礎上規劃我們的網站。避免這些問題會容易得多。考慮到我們的具體情況，這實際上是可能的。謝謝！ – Polaris878 2010-09-08 20:17:25
如果在URL中的數據自動生成不能在需要的時候，你只需再次產生的呢？
很少的信息，很難想到了解決辦法，但我希望通過研究什麼REST風格的架構中使用超媒體（即鏈接），以保持狀態方面做開始。 實踐中的休息（http://tinyurl.com/287r6wk）是關於這個話題的非常好的書。
不確定你使用的是什麼應用程序。我有同樣的問題，我用一對夫婦的解決方案（ASP.NET）：
，如果你不希望將數據推入會話我說，你的選擇變得非常有限，真的，真的取決於網址中包含什麼樣的信息的。包含長期丘吉爾報價的URL如果要自行生效，將難以壓縮;一個包含可縮寫的狀態信息（比如'q'而不是'query'，固定類別或常量的縮寫ID）可能更容易。 – 2010-09-08 19:07:09