HTTP Cookies are a simple work around to the intrinsic statelessness of the HTTP protocol. The basic idea is that the server sends an extra header with an HTTP response. The header might look like this:
Set-Cookie: attribute=value; domain=.arachna.com; path=/edu; expires=Thu, 24-Jun-2004 00:37:39 GMT; secure
Here'a breakdown of components of a Set-Cookie header:
Name/Value Pair attribute=value required -- this is the basic data payload. The value can be a URL encoded string with additional parameters in there but from the cookie "envelope" view, there's just a name and a value.
Domain Scope domain=.arachna.com optional -- by default the browser is supposed to only send the cookie back to the host it accessed when the cookie was issued. However, the host www.arachna.com can set a cookie for ".arachna.com" such that any web hosts accessed with the arachna.com domain name would get the cookie as well.
Path Scope path=/edu optional -- this will limit the URI path for which the cookie should be sent back, the default is all URI's (i.e. the equivalent of "path=/")
Expiration expires=Thu, 24-Jun-2004 00:37:39 GMT optional -- by default the cookie will last as long as the browser is open ("a session"). If the expiration is set to sometime in the future, the cookie will be persisted by the browser (usually, that's a text file or a bunch of text files). To expire a persistent cookie, it must be reissued with the expiration set to sometime in the past.
SSL flag secure optional -- this tells the browser that the cookie should only be returned via the HTTPS (HTTP over an SSL connection) protocol
As long as all of the constraints are fulfilled, the browser's responsibility is to simply return the name/value pair in the request headers:
Cookie: attribute=value
The browser should continue to do this until the cookie is expired or the session ends.