|
|
|
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). |
|