The HTTP headers that contain cookie information use commas, semicolons, and whitespace as delimiters.  This means that if you want your cookie values may contain such characters, they must be replaced with something else.  Otherwise, the header could be badly formed and the browser and/or server will not parse it as you wish.

The original Netscape cookie proposal (http://wp.netscape.com/newsref/std/cookie_spec.html) has this paragraph:

''NAME=VALUE''

''This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required.''

The official cookie RFC (http://www.ietf.org/rfc/rfc2965.txt) makes no such recommendation.  It does provide for a ''quoted-string'' representation of a cookie value, but it also warns against using such a representation due to potential incompatibility with browsers that follow the original Netscape spec.

Many applications use cookies only for session or user ID values, where the problematic characters will not appear.  But if you are using cookies that could contain commas, semicolons, or whitespace, then you need to make sure that your web application framework encodes/decodes the values properly, or that you explicitly make the necessary conversions.

The Http Client project from http://jakarta.apache.org/ contains all the encodings one needs.

With AspDotNet, it seems one can use the Http''''''Utility.Url''''''Encode() and Http''''''Utility.Url''''''Decode() methods on the values.  The actual documentation is vague about exactly what these functions do, but in practice they properly handle the problematic characters even though URL encoding does not require translation of semicolons and commas.

Much of the sample Perl CGI code available on the Internet does not encode cookie values.

----
See also AboutCookies, WebsitePatterns