Cookie中允许的字符 [英] Allowed characters in cookies

问题描述

这是一个快速：

Cookie名称和值中允许的字符是什么？它们与URL或一些常见的子集相同？

原因我问的是，我最近碰到一些奇怪的行为与cookie

解决方案

您可能认为它应该是，但实际上它不是

Cookie名称和值中允许使用的字符是什么？

根据古代Netscape的 cookie_spec 整个 NAME = VALUE 字符串是：

逗号和空格。

所以 - 在我在这里的浏览器OK;

• > = 是合法的，但可能含糊不清。浏览器总是将字符串中的第一个 = 符号的名称和值拆分，因此在实践中可以将 =

没有提及，因为Netscape在编写规格时可怕，但似乎是始终由浏览器支持：

• NAME或VALUE可能是空字符串




• 如果字符串中没有 = 符号，浏览器会将其视为具有空字符串名称的cookie，即 Set-Cookie：foo 与 Set-Cookie：= foo 相同。




• 当浏览器输出具有空名称的Cookie时，它们省略等号。因此 Set-Cookie：= bar begets Cookie：bar 。






• 控制字符（<$>

  c $ c> \x00 至 \x1F 加上 \x7F ）aren不允许

未提及的内容和浏览器完全不一致，是非ASCII（Unicode）字符：

• 在Opera和Google Chrome中，它们使用UTF-8编码为Cookie标头;


• 在IE中，使用计算机的默认代码页（特定于区域设置且从不使用UTF-8）;


• Firefox（和其他基于Mozilla的浏览器） 16代码点（因此ISO-8859-1可以，但是其他任何东西都被破坏）;


• Safari只是拒绝发送任何包含非ASCII字符的cookie。

因此在实践中，您不能在Cookie中使用非ASCII字符。如果你想使用Unicode，控制代码或其他任意字节序列，cookie_spec要求你使用自己选择的ad-hoc编码方案，并建议URL编码（由JavaScript的 encodeURIComponent ）作为合理的选择。

在实际标准方面，实际上反映了现实世界。

• RFC 2109 试图编译和修复原始Netscape cookie_spec。在此标准中，不允许使用更多的特殊字符，因为它使用 RFC 2616 令牌 - 仍在 允许），并且只能在带有其他字符的带引号字符串中指定该值。




• RFC 2965 是另一回事，整理2109并在版本2饼干计划下添加更多功能。没有人实现任何一个。




• RFC 6265 是一个HTML5时代的尝试，以清除历史的混乱。它仍然不匹配现实，但是它比早期的尝试更好 - 它至少是什么浏览器支持的正确的子集，不介绍任何应该工作，但不是（像以前的引用字符串）的语法，

在6265中，Cookie名称仍指定为RFC 2616 令牌，这意味着你可以从alphanums加上：

 ！＃$％&'* +。 ^ _` |〜
  

在cookie值中，它正式禁止（由浏览器过滤） （不一致实现）非ASCII字符。它保留cookie_spec禁止空格，逗号和分号，除了与任何实际实现早期RFC的穷人的兼容性，它还禁止反斜杠和引号，除了引号包装整个值（但在这种情况下，引号仍然被认为是一部分该值，而不是编码方案）。所以，你留下的字母加上：

 ！＃$％&'（）* +  - 。 =>？@ [] ^ _`{|}〜
  

使用原始和最坏的Netscape cookie_spec，所以代码消耗cookie应该准备好迎接几乎任何东西，但对于生成cookie的代码，建议坚持RFC 6265中的子集。

this one's a quickie:

What are the allowed characters in both cookie name and value? Are they same as URL or some common subset?

Reason I'm asking is that I've recently hit some strange behavior with cookies that have - in their name and I'm just wondering if it's something browser specific or if my code is faulty.

解决方案

this one's a quickie:

You might think it should be, but really it's not at all!

What are the allowed characters in both cookie name and value?

According to the ancient Netscape cookie_spec the entire NAME=VALUE string is:

a sequence of characters excluding semi-colon, comma and white space.

So - should work, and it does seem to be OK in browsers I've got here; where are you having trouble with it?

By implication of the above:

• = is legal to include, but potentially ambiguous. Browsers always split the name and value on the first = symbol in the string, so in practice you can put an = symbol in the VALUE but not the NAME.

What isn't mentioned, because Netscape were terrible at writing specs, but seems to be consistently supported by browsers:

• either the NAME or the VALUE may be empty strings

• if there is no = symbol in the string at all, browsers treat it as the cookie with the empty-string name, ie Set-Cookie: foo is the same as Set-Cookie: =foo.

• when browsers output a cookie with an empty name, they omit the equals sign. So Set-Cookie: =bar begets Cookie: bar.

• commas and spaces in names and values do actually seem to work, though spaces around the equals sign are trimmed

• control characters (\x00 to \x1F plus \x7F) aren't allowed

What isn't mentioned and browsers are totally inconsistent about, is non-ASCII (Unicode) characters:

• in Opera and Google Chrome, they are encoded to Cookie headers with UTF-8;
• in IE, the machine's default code page is used (locale-specific and never UTF-8);
• Firefox (and other Mozilla-based browsers) use the low byte of each UTF-16 code point on its own (so ISO-8859-1 is OK but anything else is mangled);
• Safari simply refuses to send any cookie containing non-ASCII characters.

so in practice you cannot use non-ASCII characters in cookies at all. If you want to use Unicode, control codes or other arbitrary byte sequences, the cookie_spec demands you use an ad-hoc encoding scheme of your own choosing and suggest URL-encoding (as produced by JavaScript's encodeURIComponent) as a reasonable choice.

In terms of actual standards, there have been a few attempts to codify cookie behaviour but none thus far actually reflect the real world.

• RFC 2109 was an attempt to codify and fix the original Netscape cookie_spec. In this standard many more special characters are disallowed, as it uses RFC 2616 tokens (a - is still allowed there), and only the value may be specified in a quoted-string with other characters. No browser ever implemented the limitations, the special handling of quoted strings and escaping, or the new features in this spec.

• RFC 2965 was another go at it, tidying up 2109 and adding more features under a ‘version 2 cookies’ scheme. Nobody ever implemented any of that either. This spec has the same token-and-quoted-string limitations as the earlier version and it's just as much a load of nonsense.

• RFC 6265 is an HTML5-era attempt to clear up the historical mess. It still doesn't match reality exactly but it's much better then the earlier attempts—it is at least a proper subset of what browsers support, not introducing any syntax that is supposed to work but doesn't (like the previous quoted-string).

In 6265 the cookie name is still specified as an RFC 2616 token, which means you can pick from the alphanums plus:

!#$%&'*+-.^_`|~

In the cookie value it formally bans the (filtered by browsers) control characters and (inconsistently-implemented) non-ASCII characters. It retains cookie_spec's prohibition on space, comma and semicolon, plus for compatibility with any poor idiots who actually implemented the earlier RFCs it also banned backslash and quotes, other than quotes wrapping the whole value (but in that case the quotes are still considered part of the value, not an encoding scheme). So that leaves you with the alphanums plus:

!#$%&'()*+-./:<=>?@[]^_`{|}~

In the real world we are still using the original-and-worst Netscape cookie_spec, so code that consumes cookies should be prepared to encounter pretty much anything, but for code that produces cookies it is advisable to stick with the subset in RFC 6265.

这篇关于Cookie中允许的字符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！