Разрешенные символы в cookies

это по-быстрому:

вы можете подумать, что это должно быть, но на самом деле это совсем не так!

каковы разрешенные символы в имени и значении cookie?

согласно древнему Netscape cookie_spec весь NAME=VALUE строка:

последовательность символов, исключая двоеточие, запятую и Пробел.

так - должны работайте, и, похоже, все в порядке в браузерах, которые у меня есть; где у вас проблемы с этим?

по смыслу выше:

• = законно включать, но потенциально неоднозначно. Браузеры всегда разделяют имя и значение на первое = символ в строке, поэтому на практике можно поставить = символ в значении, но не имя.

что не упоминается, потому что Netscape были ужасны при написании спецификаций, но кажется, постоянно поддерживается браузерами:

• либо имя, либо значение может быть пустыми строками

• если нет = символ в строке вообще, браузеры рассматривают его как cookie с именем пустой строки, т. е. Set-Cookie: foo это то же самое, что Set-Cookie: =foo.

• когда браузеры выводят файл cookie с пустым именем, они опускают знак равенства. Так что Set-Cookie: =bar порождает Cookie: bar.

• запятые и пробелы в именах и значениях действительно работают, хотя пробелы вокруг знака равенства обрезаются

• управляющие символы (\x00 to \x1F плюс \x7F) не допускается

что не упоминается, и браузеры полностью непоследовательны, это символы, отличные от ASCII (Unicode):

• в Opera и Google Chrome они кодируются в Cookie заголовки с UTF-8;
• в IE используется кодовая страница машины по умолчанию (специфичная для локали и никогда UTF-8);
• Firefox (и другие браузеры на базе Mozilla) используют низкий байт каждой кодовой точки UTF-16 самостоятельно (так что ISO-8859-1 в порядке, но все остальное искажено);
• Safari просто отказывается отправлять файлы cookie, содержащие символы, отличные от ASCII.

поэтому на практике вы вообще не можете использовать символы, отличные от ASCII, в cookies. Если вы хотите использовать Unicode, управляющие коды или другие произвольные последовательности байтов, cookie_spec требует, чтобы вы использовали специальную схему кодирования по своему выбору и предлагали URL-кодирование (как произведено JavaScript encodeURIComponent) как разумный выбор.

С точки зрения фактический стандарты, было несколько попыток кодифицировать поведение cookie, но до сих пор ни одна из них фактически не отражает реальный мир.

• RFC 2109 была попытка кодифицировать и исправить оригинальный Netscape cookie_spec. В этом стандарте многие другие специальные символы запрещены, так как он использует RFC 2616 токены (a - is еще разрешено), и только значение может быть указано в строке с кавычками с другими символами. Ни один браузер никогда не реализовывал ограничения, специальную обработку цитируемых строк и экранирование или новые функции в этой спецификации.

• RFC 2965 была еще одна попытка, уборка 2109 и добавление дополнительных функций по схеме "cookies версии 2". Никто никогда не реализовывал ничего из этого. Эта спецификация имеет те же ограничения токенов и цитируемых строк, что и более ранняя версия, и это такая же ерунда.

• RFC 6265 - это попытка эпохи HTML5 очистить исторический беспорядок. Он по-прежнему не соответствует реальности, но это намного лучше, чем предыдущие попытки-это, по крайней мере, правильное подмножество того, что браузеры поддерживают, не вводя синтаксис, который должен работать, но не работает (как и предыдущая цитируемая строка).

в 6265 имя файла cookie по-прежнему указывается как RFC 2616 token, что означает, что вы можете выбрать из алфавитов плюс:

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

в значении cookie он формально запрещает (отфильтрованные браузерами) управляющие символы и (непоследовательно реализованные) символы, отличные от ASCII. Он сохраняет запрет cookie_spec на космос, запятую и точка с запятой, плюс для совместимости с любыми бедными идиотами, которые фактически реализовали более ранние RFCs, он также запретил обратную косую черту и кавычки, кроме кавычек, обертывающих все значение (но в этом случае кавычки по-прежнему считаются частью значения, а не схемой кодирования). Так что оставляет вас с alphanums плюс:

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

в реальном мире мы все еще используем оригинальный и худший Netscape cookie_spec, так что код, который потребляет печенье должны быть готовы столкнуться довольно многое, но для кода, который производит куки, рекомендуется придерживаться подмножества в RFC 6265.