(4) 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 [Web Foundations (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

(5) 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

(6) 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

(7) State in HTML or HTTP

(8) State in the Server Application

(9) State as a Resource

(10) 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

(11) Reusing Resources

(13) Tracking Sessions with Cookies

• Invented as a way to compensate for HTTP's lack of state
  • session state is sent to the browser as a small file called a cookie
  • the browser sends the cookie back to the server with each request
• Cookies do not contain code that is executed
  • some data that represents session state (by value or by reference)
  • this data is stored by the browser and returned to the server
  • the browser is not supposed to interpret the data in any way
• Any server to which a browser makes a request can send back a cookie with the response

(14) Cookies for State Management

(20) Cookie Support

• Authentication can be tracked with HTTP Authentication [Web Foundations (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

(21) 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

(22) Hidden Form Fields

• Cookie [Cookie (1)]s transmit session information via HTTP
• URI Rewriting [URI Rewriting (1)] encodes session information in URIs
• Forms Basics [Anatomy of a Basic Web Application; Forms Basics (1)] 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

(24) Problems with Cookies

• Multiple browser windows
  • Suppose I am buying two different plane tickets from the same site, with two different browser windows open
  • Both windows send back the same cookies
  • No way for the site to distinguish two different sessions
• Large amounts of "state" data
  • Examples: offline access to web-based email or web-based documents (e.g. Gmail or Google Docs)
  • A "session" may stretch over many days and multiple windows
  • Too much data to send back and forth with every request and response

(25) HTML5 Web Storage

• Intended to address these problems with cookies
• Client data is stored [http://html5demos.com/storage] in a database in the web browser
• Two kinds of storage
  • session storage is meant to address the multiple-window problem
  • local storage is meant to address the offline data problem