A few months ago while helping to debug a cookie character-encoding problem, I randomly suggested trying the Java J2EE javax.servlet.http.Cookie’s setVersion(1) call, based on the RFC 2109/RFC 2965 claims that cookies labeled version 1 would behave differently. This was a foolish idea, since the cookie RFCs have little or nothing to do with the de-facto cookie non-standard.

Cookie c = new Cookie('Key", "Value");
c.setVersion(1);

Unfortunately, what was meant to be a one-line experiment got checked in, and was silently adding the Version and Discard attribute to cookies for months (note, the Discard attribute signifies a session cookie according to RFC 2965). All the common browsers ignore the version/discard attributes, so no problems appeared. Some typical output from GAE‘s Jetty server:

Set-Cookie: Key=Value;Version=1;Path=/;Discard

However, the recent Mac OS X 10.6.5 update included a security patch to CFNetwork involving cookies and allowed domains. The patch has caused problems for web-developers using local IP-addresses. It also appears that this patch silently changed how Safari treats cookies with the version/discard attribute — rather then simply ignoring the attributes, Safari now actively rejects cookies with version/discard attributes.

Is this a bug in Safari? Or a cookie-validation feature? With no real standard to measure it by, there is no way to tell. Suffice it say, it is best to avoid calling setCookie(1)!