Cookies

1. Cookies

2. Motivation • basic HTTP is stateless • some applications require knowledge of a sequence of request/response messages • e.g. shopping cart • half-baked solutions: • REMOTE_ADDR variable • id field with every link

3. REMOTE_ADDR variable • for exchanges where state is important, record the value of the REMOTE_ADDR variable • problems: • many users of a single machine • wrecked by intermediate proxies/caches

4. id field with every link • every page in a web site is dynamically generated • when a request for page comes in without an id field, generate a new id and attach it to every link on the page: • . . . <a href=”page2.pl?id=1234”> . . . </a> • . . . <form action=”additem.pl?id=1234”> . . . • every other page on the site propagates the id

5. id field: problems • if the user leaves the site and returns, the id may be lost • every page on the site must be dynmaically generated and cannot be cached (loads the web server) • if the user restarts the browser, the id may be lost

6. Cookies • name=value pairs stored on the client • sent in a response message with the Set-cookie: header • sent in a request message with the Cookie: header

7. Set-Cookie: header Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

8. expires=DATE • optional • if not present, the cookie is discard once the client program terminates • DATE, of the form: Wdy, DD-Mon-YYYY HH:MM:SS GMT

9. domain=DOMAIN_NAME • optional • defaults to FQHN in the requeste URI • suffix for domains which the cookie should be included in subsequent request messages

10. path=PATH • optional • defaults to path for the entire URI • prefix for URIs which the cookie should be included in subsequent request messages

11. secure • optional, if specified indicates cookie should only be sent over https: connections

12. Example Set-Cookie: ANON_ID=MKMMFDNMDUZ; path=/; domain=.tribalfusion.com; expires=Fri, 01-Jan-2038 00:00:00 GMT;

13. Cookie: header Cookie: NAME1=VALUE1; NAME2=VALUE2; ...