Of course, to the question in the subject, I'm sure you are saying: “ah-doyyy...“ And to that, I say that “ah-doyyy“ is an expression that isn't used nearly enough these days.
Anyway, if you are working with cookies, then you should read this article on MSDN about “HTTP-only” cookie support in IE6 SP1. These cookies are not accessible programmatically, which vastly reduces the risk of cross-site scripting attacks being able to steal the cookie.
We use HTTPOnly on the cookies we send down when using forms-based authentication in Exchange 2003. Because the users' credentials are stored in a cookie (encrypted and secured to the best of our abilities (aka “up the wazoo“), the algorithms were reviewed multiple times by the security experts at Microsoft), the risk of cross-site scripting stealing a cookie is a worrisome one. If clients are using IE6 SP1, they will have this extra layer of protection in place.
Note: If you decide to key the sending of HTTPOnly cookies off of the browser version (or key the entire feature for which security is important) rather than sending HTTPOnly all of the time, see the note at the bottom - IE6 and IE6SP1 have the same user-agent, so you need to use script to determine the minor version number.
This is in violation of RFC 2109, which defines Set-Cookie.
If the server sends this only with Set-Cookie2, defined in RFC 2965, it's at least less ambiguous.
Explanation: old, netscape Set-Cookie format was k=v; k=v. 2109 specified instead:
k=v *( ";" attr=value) *( "," k=v *(;attr=value))
this was problematic because naive clients parsing netscape-style crap would think that the attributes were cookies, and would end up returning cookies of Path=/ and stuff.
Set-Cookie2 should be preferred for all modern applications. I'm not really sure if there are any browsers that don't support it. It's kind of retarded that 2109 defined a broken, not-backwards-compatible syntax for 2109.