从JBoss 4升级到JBoss 5之后，我注意到了最烦人的回归。它截断了base64 cookie值的尾随等号（'='）。
我花了很多时间才明白问题不是我的代码而是JBoss'，我用Google搜索并发现它是一个已知的issue。
建议的解决方法是计算字符串长度并用尾随等号填充它（长度为4的多重性）。
由于我们的应用程序可以运行在多个应用程序服务器上（例如WebLogic，WebSpehere），我非常不愿意添加这段特殊于此版本JBoss的代码。
有没有人遇到过这个？你能建议一个更聪明的解决方法吗？
编辑：感谢@skaffman我理解我的问题，我不应该首先使用base64 for cookie string。基础64上有一个名为base64 url的变体，应该用于这样的字符串（cookies，urls ......）。例如，Apache编解码器库在其基础64实现中支持该变体。
答案 0 :(得分：6)
您是否可以控制Cookie的创建和编码/解码方式？如果是这样，那么你可以切换到另一种编码机制，一种不使用可能与cookie规范冲突的字符的机制。例如，Apache Commons Codec包括Hex类，它可以对二进制数据进行编码和解码。它比base64中的等效数据大，但这可能无关紧要。
或者，您可以稍微使用Cookie API。 Cookie.setValue()的javadoc说：
使用版本0 cookie，值应该 不包含空格，括号， 括号，等号，逗号， 双引号，斜线，问题 标志，标志，冒号和 分号。空值可能不会 在所有浏览器上表现相同。
从技术上讲，base64编码与版本0 cookie不兼容，这可能是默认值。您可以尝试在Cookie上调用setVersion(1)，看看是否会产生影响，尽管您可能会遇到浏览器兼容性问题。
答案 1 :(得分：1)
如果我正确理解错误报告，编码器的正确实现将始终产生一个4的倍数的字符串，因此如果添加错误修复，它将不会在除JBoss之外的其他应用服务器中触发。因此，您的代码将适用于所有服务器。在旁注中，也许您可以将其实现为servlet过滤器，这对您的app来说是最小的侵入。
答案 2 :(得分：1)
对于jboss 5设置以下系统属性：
org.apache.catalina.STRICT_SERVLET_COMPLIANCE =假
- 巴拉