3

根据RFC 2109，cookie 的值“对用户代理是不透明的，可以是源服务器选择发送的任何内容，可能是服务器选择的可打印 ASCII 编码。”

因此，即使原始值相同，不同的语言/平台/服务器也会发送不同的 cookie 值。

例如，C#/ASP.NET 按原样发送文本；经典的 ASP urlencodes 和 urldecodes 文本；Perl/Apache urlencodes/decodes 文本（但与 ASP 不同！）。PHP 为您提供了选择。

我正在编写一个需要与完全不同的应用程序共享 cookie 的单点登录系统。特别是我有 .NET、Java、Perl、ColdFusion 需要开箱即用的支持。

我存储在 cookie 中的文本始终是有效的ASCII-7字符串。然而，例如，Perl 喜欢对一些 7 位 ASCII 字符进行编码。

我看到了两个主要的替代方案来完成这项工作：

  1. 只接受非编码值。毕竟没有必要对它们进行编码。这就是目前的情况。显然，所有集成系统都必须能够支持非编码值。

  2. 接受编码和非编码值。这将允许开箱即用的最大兼容性，但我需要确定是否对特定值进行了编码（这听起来很不可能：“%20”是文字“%20”字符串还是空格？）

您会建议哪种解决方案，为什么？如果是 #2，您将如何检测 UrlEncoded 文本？

cookie 示例（我添加了换行符以使其适合）

A5A2794D694241AD92F9B22F288EFAA1|8428DCCC|20090821142732|20090821142832|
10.100.107.40|955098D50AB4982D4E247EFA53F4E23B32A05ED0131E096709BE1D8CCC
8A3CA18252D376473C244FD71C462AB42CF54C
4

2 回答 2

3

是的，这不是一个小问题。从根本上说，我更倾向于解决方案#2，因为它是最具互操作性的。但是，正如您所说，检测哪些 cookie 是 URL 编码的，哪些不是，这是一个非常重要的问题。

我想到的一件事是，您可以使用一些特殊字符来填充 Cookie 值的开头，这样您就可以检测 Cookie 是否已编码。当然，这可能不会涵盖所有客户端，但是例如，如果您的正常 cookie 值是这种形式，CookieValue1234那么您可以将其更改为head :CookieValue1234并检查其中的空间是否会返回 URL 编码（即返回为" %20" 或作为 " ")。

于 2009-08-21T14:01:18.377 回答
1

有什么理由不能使用纯字母数字值？如果你有不透明的二进制数据，你想保留，那么你可以使用十六进制或使用“网络安全”base64。

你越不可能让任何人弄乱你的cookie ， IMO就越好。

于 2009-08-21T14:19:29.023 回答