從JBoss 4升級到JBoss 5後，我注意到了最令人討厭的迴歸。它截斷了base64 cookie值的尾部等號（'='）。JBoss 5截斷了base64 cookie字符串的尾部
花了我很多時間才明白，問題不是我的代碼，但JBoss'，我GOOGLE了它，發現它是一個已知的issue。
建議的解決方法是計算字符串長度並用拖尾等號（長度爲4的長度）填充它。由於我們的應用程序可以在多個應用程序服務器（例如WebLogic，WebSpehere）上運行，所以我非常不願意爲這個版本的JBoss添加這段代碼。
有沒有人遇到過這個？你能提出一個更智能的解決方法嗎？
編輯：感謝@skaffman我明白我的問題，我不應該首先使用base64作爲cookie字符串。在基礎64上有一個名爲base64 url的變體，應該用於這樣的字符串（cookie，url ...）。例如，庫的Apache編解碼器在其基本的64實現中支持這個變體。
您是否可以控制Cookie的創建和編碼/解碼方式？如果是這樣，那麼你可以切換到另一種編碼機制，一種不使用可能與cookie規範衝突的字符。例如，Apache Commons Codec包括一個Hex類，它可以將二進制數據編碼和解碼爲十六進制字符串。它會比base64中的等效數據更大，但這可能並不重要。
或者，您可以使用Cookie API稍微玩一下。對於Cookie.setValue()的Javadoc說：
隨着版本0的cookie，值應該 不能包含空格，方括號， 括號，等號，逗號， 雙引號，斜槓，質疑 標誌，在標誌，冒號和 分號。在所有瀏覽器上，空值可能不是 的行爲方式相同。
從技術上講，base64編碼與版本0 cookie不兼容，可能是默認值。您可以嘗試在cookie上調用setVersion(1)，然後查看是否有所作爲，但是您仍有可能遇到瀏覽器兼容性問題。
如果我正確理解錯誤報告，編碼器的正確實現將總是生成一個4的倍數的字符串，所以如果添加錯誤修復，它將不會在除JBoss之外的其他應用程序服務器中觸發。您的代碼將在所有服務器上運行。在一個側面說明，也許你可以實現它作爲一個servlet過濾器，這將是最低限度侵入你的應用程序。
對於JBoss 5中設置下面的系統屬性：
org.apache.catalina.STRICT_SERVLET_COMPLIANCE =假
--bala
哦，我不知道這些東西......作爲一個事事實上，我確實可以控制Cookie的創建，因此我會按照您的建議檢查其他格式。謝謝。 – LiorH 2009-11-08 20:11:35