HTTP Lecture

HTTP-Lecture.rb

# Each new HTTP request (from client -> server) uses a new TCP/IP connection.

# New connection == meeting the the fist time. There's nothing inherent in HTTP that allows a server to remember who is who.

# Why would the server need to track miultiple users?


# Hacking state onto HTTP ------------

# Tracking 'state' i.e. data

# Sending data with HTTP: GET, POST, PUT, DELETE
# ---- Query params: http://facebook.com/?current-user=someone
# ---- Requesting the body
# ---- Headers with data (meta tags)

# Cookies
# --- Cookie is an HTTP header. Both client and server agree to populte this header.
# --- Cookies can be created/changed/deleted locally (in browswer) or in the server.
# --- Changes to cookes for the domain are shared via the Cookies header ( included in both the request and response)
# --- Browsers save cookies locally. Servers don't store cookies.

# Security
# --- What's the risk
    cookies[:user_id] = @user.id
# --- You can't trust clients
    Cookie.set('user_id', 1)
    
# Performance and Simplicity.
# ---- Storing session data in the database can become a performance bottleneck 
# and make it difficult to scale horizontally.
# ---- If we're willing to limity storage, we can be crafty and put a session
# in a cookie.


# Cookies are unique to a client and domain
# Your browser only sends the cookeis for the domain it's sending the request to Your app server
# won't see a user's cookies for other domains, like Facebook, and Facebook won't
# see yours. 


#  Sinatra stoes the entire sessions in a cookie. 
#  All modern implementations of a session depends on a  cookie to maintain some 
#  state.
# With as little as the session's identifier and as much as the entire session's 
# data.