this is a phenomenon i have long wondered about, myself, the answer to which came to light upon reading further into rfc-2109 after yesterday’s post.

so why can you not serve a ‘plain vanilla’ cookie (only name or name and expires attributes provided) during a redirect and expect it to still be there afterward? security.

to quote the above rfc:

unverifiable transactions typically arise when a user agent… resolves redirection (3xx) responses from an origin server… when it makes an unverifiable transaction, a user agent must enable a session only if a cookie with a domain attribute D was sent or received in its origin transaction, such that the host name in the request-uri of the unverifiable transaction domain-matches D.

this restriction prevents a malicious service author from using unverifiable transactions to induce a user agent to start or continue a session with a server in a different domain.

so now you know. if you really want to construct your application such that cookies get served ‘between’ pages (i.e. upon completion of a script that processes a form and then redirects to an appopriate follow-up or confirmation page), you need to serve a fully-qualified cookie (domain included and most likely path also, e.g. ‘Set-Cookie; variable=…; domain=…; path=/; expires=…’).

and to think that for years i never knew this behavior was by design, and have implemented methods to ensure that my cookies always get served on the arrival page after any redirect — as you can imagine this method requires not-so-nice forwarding and later detection of data delivered in get or post variables; not to mention that the set-cookie headers themselves must be echoed before any content is delivered (lest ye see a “headers already sent” error).