I was reading the chapter on session management, although the question is not any book specific.
It said, cookies live as long as the number of seconds set in cookie.setMaxAge(ageInSeconds). Agreed. If the user shuts down his browser/machine and returns within that period, the cookie would still be alive and therefore usable.
But what differentiates cookies from one app to another. If the user visits App A and App B, how does App B know it is reading it's own cookie and not the cookie set by App A?
Might be I am getting ahead of myself, but worth knowing anyways.
Hi Suhas ,
Please have a look at this information.This would help you.
Beside the name/value pair, a cookie may also contain an expiration date, a path, a domain name, and whether the cookie is intended only for encrypted connections. RFC 2965 also specifies that cookies must have a mandatory version number, but this is usually omitted. These pieces of data follow the name=newvalue pair and are separated by semicolons. For example, a cookie can be created by the server by sending a line Set-Cookie: name=newvalue; expires=date;path=/; domain=.example.org.
Example of an HTTP response from google.com, which sets a cookie with attributes.
The domain and path tell the browser that the cookie has to be sent back to the server when requesting URLs of a given domain and path. If not specified, they default to the domain and path of the object that was requested. As a result, the domain and path strings may tell the browser to send the cookie when it normally would not. For security reasons, the cookie is accepted only if the server is a member of the domain specified by the domain string.
Cookies are actually identified by the combination of their name, domain, and path, as opposed to only their name (the original Netscape specification considers only their name and path). In other words, same name but different domains or paths identify different cookies with possibly different values. As a result, cookie values are changed only if a new value is given for the same name, domain, and path.
The expiration date tells the browser when to delete the cookie. If no expiration date is provided, the cookie is deleted at the end of the user session, that is, when the user quits the browser. As a result, specifying an expiration date is a means for making cookies survive across browser sessions. For this reason, cookies that have an expiration date are called persistent.
The expiration date is specified in the "Wdy, DD-Mon-YYYY HH:MM:SS GMT" format. As an example, the following is a cookie sent by a Web server (the value string has been changed):
Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.example.net
The name of this particular cookie is RMID, while its value is the string 732423sdfs73242. The server can use an arbitrary string as the value of a cookie. The server may collapse the value of a number of variables in a single string, like for example a=12&b=abcd&c=32. The path and domain strings / and .example.net tell the browser to send the cookie when requesting an arbitrary page of the domain .example.net, with an arbitrary path.
Joined: May 16, 2006
Thanks for the detailed explanation Niteen.
From what I read and understood, I believe, when a user makes a request to a particular domain, the browser determines from it's cookie cache which cookie to use based on the name, path and domain name in the cookie that matches the server domain.
Am I correct?
Basically, what I was thinking was, if the browser decides which cookie to use based on the above criteria, will having a large number of cookies on the client machine be an overhead in making further requests. Will it slow down the request(NOT response) speed? Even if a cookie expires, the browser will still need to find out if the cookie still alive or not, won't it?
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com