I can't seem to figure out how to create a persistent vs a non-persistent cookie. How do they differ, say, in the HTTP headers that are sent back?
+1
A:
Cookies have an expiration date implicitly or explicitly set which controls how long they last (subject to the user agent actually enforcing it). A cookie may persist only for the duration of the session (or an even shorter period).
If a cookie is valid, it will be passed along with the HTTP request to the domain that it originated from. In other words, only the domain that set the cookie can read the cookie (though there are ways to exploit this, such as cross-site scripting).
Essentially, if you want a cookie to hang around for a while, set an expiration date on it that is far into the future using the client or server-side language of your choice.
EDIT: If you want the cookie to expire when the session ends, don't set an expiration date. See a more formal definition:
The cookie setter can specify a deletion date, in which case the cookie will be removed on that date. If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser. As a result, specifying a date is a way for making a cookie survive across sessions. For this reason, cookies with an expiration date are called persistent. As an example application, a shopping site can use persistent cookies to store the items users have placed in their basket. (In reality, the cookie may refer to an entry in a database stored at the shopping site, not on your computer.) This way, if users quit their browser without making a purchase and return later, they still find the same items in the basket so they do not have to look for these items again. If these cookies were not given an expiration date, they would expire when the browser is closed, and the information about the basket content would be lost.
http://en.wikipedia.org/wiki/HTTP_cookie
Or, you can read the actual RFC (note page 5)
Tim
2010-10-06 06:21:00
And if I only want the cookie to persist for the session, what expiration should I set?
Chung Wu
2010-10-06 17:53:54
Please see my edit.
Tim
2010-10-06 18:34:40
Thanks! Does that mean any Set-Cookie without an expires clause will be a session cookie, and will be lost once the browser restarts? Because that's not what I see... Once I do a Set-Cookie without expires, and restart the browser, I can still read that cookie back. Is that expected?
Chung Wu
2010-10-06 19:00:43
I double-checked to make sure and posted some additional links. What language/web server are you running that you are seeing this behavior?
Tim
2010-10-06 19:11:40
Man, I'm sorry for turning this into a debugging session! I'm using pylons, but I'm just looking at the HTTP headers right now. After doing Set-Cookie key=something; path=/;, restarting the browser, and reloading the page, I see that cookie still in the request. Not sure what else I'm missing...
Chung Wu
2010-10-06 20:26:12
No worries. If you look at the actual file system, can you see the cookie stored there? In IE on Vista/Windows 7, the cookies should be in C:\Users\[user name]\AppData\Local\Microsoft\Windows\Temporary Internet Files
Tim
2010-10-06 20:37:40
I finally found out what happened. On Firefox, if you turn on session restore ("When Firefox starts: Show my windows and tabs from last time"), it'll restore even the session cookies when you restart! See https://bugzilla.mozilla.org/show_bug.cgi?id=443354
Chung Wu
2010-10-13 19:26:09
That's an interesting behavior...on the one hand, it seems like a huge bug, on the other hand, I can see why non-technical users would expect their sessions to just continue. You could theoretically perform limited checks against that scenario by looking to see if the session that the cookie references actually still exists, although I have found that checks that like that can notoriously hard and prone to error. An easier way would be to just write a persistent cookie every time a page was viewed with the date, and check how long it has been since last activity.
Tim
2010-10-14 01:27:21