The RFC section that is quoted above actually refers to how servers
accept cookies, as opposed to how user-agents process cookies. I
actually don't see any place in RFC 2695 which specifies (or
prohibits) a specific delimiter inside a cookie (I could be missing
it, though; any pointers would be helpful). Regardless, you're right
that these things should be url_encoded at the very least, and that's
exactly what ACS 4.0.1 and later does:
<~> telnet developer.arsdigita.com 80
Trying 216.34.106.248...
Connected to developer.arsdigita.com (216.34.106.248).
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.0 200 OK
Set-Cookie:
ad_session_id=28646925%2c0%20%7b145%20988119842%205F3C876E8F07ECB37869B5B9C5EECB2DB17AE730%7d;
Path=/; Max-Age=1200
Content-Type: text/html; charset=iso-8859-1
MIME-Version: 1.0
Date: Tue, 24 Apr 2001 13:24:03 GMT
Server: AOLserver/3.2+ad10
Content-Length: 6967
Connection: close
I'm not familiar with the OpenACS 3.2.x code, but in ACS 4.x we
introduced a set cookie abstraction procedure (ad_set_cookie). If this
exists inside OpenACS 3.2.x, you could fix this proc instead of
running through the entire ACS as Jonathan suggests.
One more note is that getting cookies to work right is atually a pain
in the butt because most client browsers don't follow 2965 to the
letter, and you'll notice that ad_set_cookie redundantly sets headers
to cover all the known cases. It's taken us a couple of tries to get
it right (and it looks like OpenACS hasn't gotten all of the fixes
yet). In fact, even the ACS 4.2 implementation isn't quite right
because in rare cases it might fail in WAP gateways, so we're using !
as a delimeter now in ACS Java 4.0.2 and later. I actually disagree
with the comment that it's just a "silly programming error on the part
of some aD hacker", because I actually think that programming cookies
is a difficult thing and requires anal-retentive testing :).
