It's all an illusion (at the HTTP layer) |
Many web sites allow you to establish a session. | ||
you identify yourself to the system. | ||
now you can visit lots of pages, add stuff to shopping cart, establish preferences, etc. | ||
Remember that each HTTP request is unrelated to any other (as far as the Web server is concerned). | |
Each new request to a server starts up a brand new copy of the server program (a new thread, or a new process). | |
Providing sessions requires keeping state information. |
One way to propagate state information is to use hidden fields. | |
User identifies themselves to a server program (fills out a form). | |
Server sends back a form that contains hidden fields that identify the user or session. |
Initial form has field for user name. | |
GET /prog1?name=davey HTTP/1.0 | |
Prog1 creates order form with hidden field. | |
GET /prog2?name=davey&order=cookie HTTP/1.0 |
Many Web based systems use hidden fields that identify a session. | |
When the first request arrives, the system generates a unique session key and stores it in a database. | |
The session key can be included in all forms/links generated by the system (as a hidden field or embedded in a link). |
Must be unique. | ||
Should expire after a while. | ||
Should be difficult to predict. | ||
typically use a pseudo-random number generator seeded carefully. | ||
A server using session keys: | |
<INPUT TYPE=HIDDEN NAME=sessionkey VALUE=HungryStudent971890237> |
A request to order a pizza might now look like this (all on one line): | |
GET /pizza?sessionkey= HungryStudent971890237&pizza=cheese&size=large HTTP/1.0 |
A “cookie” is a name,value pair that a server program can ask the client to remember. | |
The client sends this name,value pair along with every request to the server. | |
We can also use "cookies" to propagate state information. |
Cookies are HTTP headers. | |
A server can give the browser a cookie by sending a Set-Cookie header line with the response. | |
A client can send back a cookie by sending a Cookie header line with the request. |
HTTP/1.0 200 OK | |
Content-Type: text/html | |
Set-Cookie: customerid=0192825 | |
Content-Length: 12345 | |
Favorite-Company: IBM | |
Nap-Time: 12-2 | |
... | |
The general form of the Set-Cookie header is: | |
Set-Cookie: name=value; options | |
The options include: | |
expires=... | |
domain=... | |
path=... |
This tells the browser how long to hang on to the cookie. | |
The time/date format is very specific! |
Weekday, Day-Month-Year Hour:Minute:Second GMT | |
This all must be on one line! | |
Weekday is spelled out. | |
Month is 3 letter abbreviation | |
Year is 4 digits |
If there is no expires option on the Set-Cookie header line, the browser does not save the cookie to disk. | |
In this case, when the browser is closed it will forget about the cookie. |
domain=.rpi.edu | |
The domain option tells the browser the domain(s) to which it should send the cookie. | |
Domains as in DNS. | |
The domain must start with "." and contain at least one additional "." | |
The server that sends the Set-Cookie header must be in the domain specified. | |
If no domain option is in the header, the cookie will only be sent to the same server. |
path=/ | |
or | |
path=/~hollingd/netprog | |
The path option tells the browser what URLs the cookie should be sent to. |
If no path is specified in the header, the cookie is sent to only those URLs that have the same path as the URL that set the cookie. | |
A path is the leading part of the URL (does not include the filename). |
If the cookie is sent from: | |
/~hollingd/netprog/pizza/pizza | |
it would also be sent to | |
/~hollingd/netprog/pizza/blah | |
but not to | |
/~hollingd/netprog/soda/coke |
Many options can be specified. | |
Things are separated by ";": | |
Set-Cookie: a=blah; path=/; domain=.cs.rpi.edu; expires=Thursday, 21-Feb-2002 12:41:07 2002 |
A server program can send back any number of HTTP headers. | ||
can set multiple cookies | ||
Content-Type is required! | ||
Blank line ends the headers! |
Content-Type: text/html | |
Set-Cookie: prefs=nofrms | |
Set-Cookie: Java=yes | |
… now sends document content |
Drop by Dave's office anytime! | |
If you want cookies, you might consider bringing some with you... |
The browser sends each cookie as a header: | |
Cookie: prefs=nofrms | |
Cookie: Java=OK | |
The Web server reads the cookies from the headers. CGI and servlets pass the cookies via environment variables or via the HttpServletRequest getCookies() method (which returns an array of Cookies). |
There can be more than one cookie. | |
Using CGI, the Web Server puts them all together like this: | |
prefs=nofrms; Java=OK | |
and puts this string in the environment variable: HTTP_COOKIE | |
Using Servlets, you can use: | |
…cookies[i].getName();… …cookies[i].getValue();… …cookies[i].getVersion();… | |
Each cookie can be up to 4k bytes. | |
One "site" can store up to 20 cookies on a user's machine. |
Create a session. | |
Track user browsing behavior. | |
Keep track of user preferences. | |
Avoid logins. |
Cookies can't be used to: | ||
send personal information to a web server without the user knowing about it. | ||
be used to send viruses to a browser. | ||
find out what other web sites a user has visited. | ||
access a user's hard disk |
Persistent cookies take up space on user's hard disk. | ||
Can be used to track your behavior within a web site. | ||
This information can be sold or shared. | ||
Cookies can be shared by cooperating sites (advertising agencies do this). |