(8) Tracking Sessions

• Invented as a way to compensate for HTTP's lack of state
  • application state is being sent to the client (Set-Cookie)
  • the client transmits application state in requests (Cookie)
• Cookies do not contain code that is executed
  • some data that represents application state (by value or by reference)
  • this data is stored by the client and returned to the server
  • the client is not supposed to interpret the data in any way
• Cookies can be used in many different ways
  • when used for tracking application state they are unproblematic
  • when used for tracking resource state they introduce problems

(9) HTTP and Sessions

• A session is an ongoing exchange of information, where later parts of the exchange depend on earlier parts
  • for example: buying an airline ticket from a travel web site
• The current status of a session is referred to as its state
  • for example: user has selected a specific flight for the outgoing leg of a round-trip flight, but has not yet selected a flight for the return leg
• HTTP has no session concept
  • interactions are HTTP individual request/response pairs and not "site visits"
  • HTTP/1.1 [URIs & HTTP; HTTP Performance (1)] does not change this, it is only a performance optimization
  • servers can not reliably identify users interacting with a Web site
• Sessions have to be handled at the level of Web applications built on top of HTTP

(10) Keeping Track of Session State

• Information about the current state of a session has to be stored someplace
• With server-side sessions, the state is stored by the web server
  • OK when there is just one web server, but most large web sites have many servers
  • either these servers have to share all the same state information, or a user has to keep connecting to the same server throughout the session
  • both of these are problematic
• With client-side sessions, the state is stored by the client (web browser)
  • the browser has all relevant information about a session
  • when the server restarts, no information will be lost

(11) Keeping Track of Session State

• Three basic approaches are possible
  1. sending back and forth state as part of every request and response
  2. store state in the server and refer to it from the client
  3. treat state as a resource: store state at a URI and use the URI to refer to that state

(12) State in HTML or HTTP

(13) State in the Server Application

(14) State as a Resource

(15) Stateless Shopping

• Typical session scenarios can be mapped to resources [http://www.peej.co.uk/articles/no-sessions.html]
  • Client: Show me your products
  • Server: Here's a list of all the products
  • Client: I'd like to buy 1 of http://ex.org/product/X, I am "John"/"Password"
  • Server: I've added 1 of http://ex.org/product/X to http://ex.org/users/john/basket
  • Client: I'd like to buy 1 of http://ex.org/product/Y, I am "John"/"Password"
  • Server: I've added 1 of http://ex.org/product/Y to http://ex.org/users/john/basket
  • Client: I don't want http://ex.org/product/X, remove it, I am "John"/"Password"
  • Server: I've removed http://ex.org/product/X to http://ex.org/users/john/basket
  • Client: Okay I'm done, username/password is "John"/"Password"
  • Server: Here is the total cost of the items in http://ex.org/users/john/basket
• This is more than just renaming session to resource
  • all relevant data is stored persistently on the server
  • the shopping cart's URI can be used by other services for working with its contents
  • instead of hiding the cart in the session, it is exposed as a resource

(16) Reusing Resources

(23) Cookie Support

• Authentication can be tracked with HTTP Authentication [URIs & HTTP; HTTP Authentication (1)]
  • this is possible because authentication is built into HTTP
• Other session concepts are not supported by HTTP
  • cookies have become the generic solution for all session tracking
• Cookies are increasingly limited by browsers
  • cookies have gained some notoriety as privacy invaders
  • browsers have more restrictive default settings
  • an increasing number of users restricts cookie support
• Session-oriented Web sites often depend on cookies

(24) URI Rewriting

• Cookie [Cookie (1)]s are a piece of information stored on the client
  • they are sent by the server as a result of a request
  • they are returned by the browser in a response to the same site
• The same information can also be encoded in the URI
  • normally a response contains a cookie and an HTML page
  • the same effect is achieved when all links include the cookie value
  • this method often results in very long URIs
• Some Web application frameworks switch automatically
  • J2EE checks for cookie support and switches to URI rewriting if required
• Problems with bookmarks and caches

(25) Hidden Form Fields

• Cookie [Cookie (1)]s transmit session information via HTTP
• URI Rewriting [URI Rewriting (1)] encodes session information in URIs
• HTML Forms [HTML Forms] are a way to send data to a server
  • in most cases this is data that is entered by the user
• Hidden form fields can be used to send data that is part of the HTML
  • hidden form fields are never displayed to the user
  • their predefined values are sent as part of the form submission
• Hidden form fields are essentially the same as URI Rewriting [URI Rewriting (1)]
  • they can only be used if the interaction is based on forms
  • they also require the Web page to be dynamically generated for each request
  • the values end up as URI query string or request entity

(26) Cookies for State Management

(27) Cookie Mechanics (Initial Request)

https://www.ischool.berkeley.edu/intranet

GET /intranet HTTP/1.1
Host: www.ischool.berkeley.edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.8,de-ch;q=0.5,de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
If-Modified-Since: Thu, 04 Mar 2010 20:15:49 GMT
Cache-Control: max-age=0

HTTP/1.1 403 Forbidden
Date: Thu, 04 Mar 2010 20:17:24 GMT
Server: Apache/2.2.14 (Fedora)
X-Powered-By: PHP/5.2.12
Set-Cookie: SESS00be74b89d347a8c3cb30a12b2378b79=m22t433utrc8dc2uvmn02fedc1; expires=Sat, 27-Mar-2010 23:50:44 GMT; path=/; domain=.ischool.berkeley.edu
Last-Modified: Thu, 04 Mar 2010 20:15:50 GMT
Etag: "b31bc1b24477a0bc2378e8e7bad4a101"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
Content-Encoding: gzip
Content-Length: 2205
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

(28) Cookie Mechanics (Authenticating)

https://www.ischool.berkeley.edu/intranet

POST /intranet HTTP/1.1
Host: www.ischool.berkeley.edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.8,de-ch;q=0.5,de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: https://www.ischool.berkeley.edu/intranet
Cookie: SESS00be74b89d347a8c3cb30a12b2378b79=m22t433utrc8dc2uvmn02fedc1; has_js=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 104
name=dret&pass=??????&form_build_id=form-d2937ead2a61d62e2f07fef759b858b9&form_id=user_login&op=Log+in

HTTP/1.1 302 Found
Date: Thu, 04 Mar 2010 20:23:41 GMT
Server: Apache/2.2.14 (Fedora)
X-Powered-By: PHP/5.2.12
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Thu, 04 Mar 2010 20:23:41 GMT
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Set-Cookie: SESS00be74b89d347a8c3cb30a12b2378b79=deleted; expires=Wed, 04-Mar-2009 20:23:40 GMT; path=/
Set-Cookie: SESS00be74b89d347a8c3cb30a12b2378b79=i290spebr7ucurno8f4nh9njj5; expires=Sat, 27-Mar-2010 23:57:01 GMT; path=/; domain=.ischool.berkeley.edu
Location: http://www.ischool.berkeley.edu/intranet
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

(29) Cookie Mechanics (Cookied Repeat)

http://www.ischool.berkeley.edu/intranet

GET /intranet HTTP/1.1
Host: www.ischool.berkeley.edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.8,de-ch;q=0.5,de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: SESS00be74b89d347a8c3cb30a12b2378b79=i290spebr7ucurno8f4nh9njj5; has_js=1

HTTP/1.1 301 Moved Permanently
Date: Thu, 04 Mar 2010 20:23:42 GMT
Server: Apache/2.2.14 (Fedora)
Location: https://www.ischool.berkeley.edu/intranet
Content-Length: 339
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

(35) Limitations of Cookies

• Cookies are designed to work without client-side scripting
• Cookie storage space is limited (RFC 2965 [http://www.apps.ietf.org/rfc/rfc2965.html] makes recommendations [http://www.apps.ietf.org/rfc/rfc2965.html#sec-5.3])
  • at least 300 cookies
  • at least 4096 bytes per cookie
  • at least 20 cookies per unique host or domain name
• Cookies are browser-scoped, not tab-scoped
  • many applications do not work well when used in multiple tabs
  • cookie-based interactions implicitly interact between tabs
  • Session Storage [Session Storage (1)] allows local storage to be scoped by session
• Cookies are transmitted with each interaction (HTTP mechanism)- slowing down interaction times
• Cookies are typically not encrypted when sent over HTTP except for HTTPS
  • browser manage cookie storage space automatically
  • cookies should be small (implementation limits and HTTP overhead)
  • Local Storage [Local Storage (1)] allows local storage to be managed by scripting

(36) Web Storage

• Unlike cookies Web/DOM storage is designed for client-side scripting
• Scope is determined by document origin
  • access control based on the same concepts as other Web technologies
  • handles sessions as well as (some) access control
• Storage is organized as a list of key/value pairs
  • there can only be one value per key (identification by key)
• Order is defined but not stable across changes
  • items can be requested by position (useful for scanning all items)
  • order can change when items are added or removed

interface Storage {
	readonly attribute unsigned long length;
	getter DOMString key(in unsigned long index);
	getter any getItem(in DOMString key);
	setter creator void setItem(in DOMString key, in any data);
	deleter void removeItem(in DOMString key);
	void clear();
};

(42) Local SQL Database

• Browsers often have built-in databases
  • managing fast access to history information
  • managing caching and other internal data structures
• Local applications often have sophisticated storage needs
  • relational storage is the most mainstream data metamodel
  • allowing scripting to access relational storage open new opportunities
• Browser databases are not always exposed to scripting
  • SQLite [http://www.sqlite.org/] is included in Firefox and WebKit (and many other products [http://www.sqlite.org/famous.html])
  • Firefox has decided to only allow access for add-ons (e.g., Zotero [http://www.zotero.org/])
  • WebKit exposes database access to scripts as the Web SQL Database [http://www.w3.org/TR/webdatabase/] API

(43) Minimal Web Database Demo (Create Tables)

   function loaded(){
   if (window.openDatabase){
    //openDatabase(name, version, displayname, estimatedsize, callback);
    var db = openDatabase("mystorage", "1.0", "Web Database Demo", 1*1024*1024);
    if (db) {
     drop_table_ife(db, "places");
     drop_table_ife(db, "currency");
     create_table_ifne(db);
     create_table_ifne_other(db, "currency");
     insert_values_places(db, "Mumbai", "India", 13922135);
     insert_values_places(db, "Shanghai", "China", 13831900);
     insert_values_places(db, "Karachi", "Pakistan", 12991000);
     insert_values_places(db, "Delhi", "India", 12259260);
     insert_values_places(db, "Istanbul", "Turkey", 11372613);
     insert_values_currency(db, "India", "Indian Rupee");
     insert_values_currency(db, "Pakistan", "Pakistani Rupee");
     insert_values_currency(db, "China", "Renminbi");
     insert_values_currency(db, "Turkey", "Turkish lira");
     read_and_display_values_places(db); //reads and displays values from the 'places' table
     read_and_display_values_currency(db); // reads and displays values from the 'currency' table
     do_the_join(db); //performs a JOIN query and displays the results
    } else { alert('Error opening database'); };
   } else { alert('Web SQL doesn\'t seem to be supported in this browser'); };

(44) Minimal Web Database Demo (Use Tables)

   function read_and_display_values_places(db){
    var thetable = document.getElementById('table1');
    db.transaction(
     function(t){
     t.executeSql('SELECT city as cityname, country as countryname, population as thepop FROM places', [], 
      function(t,r) {
        for (var i=0;i<r.rows.length;i++) {
         var cityname = r.rows.item(i).cityname;
         var countryname = r.rows.item(i).countryname;
         var thepop = r.rows.item(i).thepop;
         if (thetable) { thetable.innerHTML += "<tr><td scope=\"col\">"+cityname+"</td><td scope=\"col\" width=\"30%\">"+countryname+"</td><td scope=\"col\" width=\"30%\">"+thepop+"</td></tr>"; }}}, 
      function(t,e) { alert('Error:'+e.message); });});}

 <body onload="loaded()">
  <h1>Minimal <a href="http://www.w3.org/TR/webdatabase/">Web Database</a> Demo</h1>
  <p>Table: Places</p>
  <table id="table1" rules="all"><tr><th scope="col">City</th><th scope="col">Country</th><th scope="col">Population</th></tr></table>
  <p>Table: Currency</p>
  <table id="table2" rules="all"><tr><th scope="col">Country</th><th scope="col">Currency</th></tr></table>
  <p>Join of Places and Currency</p>
  <table id="table3" rules="all"><tr><th scope="col">City</th><th scope="col">Currency</th></tr></table>
 </body>

(45) Minimal Web Database Demo (Join Tables)

   function do_the_join(db){
    var thetable = document.getElementById('table3');
    db.transaction(
    function(t){
    t.executeSql('SELECT city as cityname, currency as currency FROM places, currency where places.country = currency.country', [], 
     function(t,r) {
      for (var i=0;i<r.rows.length;i++){
       var city = r.rows.item(i).cityname;
       var currency = r.rows.item(i).currency;
        if (thetable){
        thetable.innerHTML +="<tr><td scope=\"col\"> "+city+"</td><td scope=\"col\"> "+currency+"</td></tr>";}}}, 
     function(t,e) { alert('Error:'+e.message); });});}

(46) Specification Problems

• User agents must implement the SQL dialect supported by SQLite 3.6.19 [http://www.w3.org/TR/webdatabase/#web-sql]
  • not acceptable as a Web standard
  • defining a reasonable and useful subset of SQL is not easy
• Currently only usable for targeted development
  • supported by some major browsers (WebKit, maybe Opera)
  • not supported by other major browsers (Firefox, IE)
  • will probably be changed if it ever becomes a standard
• Key/Value Storage [Key/Value Storage (1)] is the better solution for storage