anchor.diff:  
   ## Inside Rack's env
   
  -The env var is a Rack app's window into the great wide HTTP. Most of what we use in our Ruby frameworks relies on env. Before data gets to us it's parsed by Rack and then injected into env. env holds everything from ACCEPT headers to session cookies and...
  +The env var is a Rack app's window into the great wide HTTP. Most of what we use in our Ruby frameworks relies on env. Before data gets to us it's parsed by Rack and then injected into env. env holds everything from ACCEPT headers to session cookies.
   
   <% note do %>
   
  
positive.code: 
  # Inside Rack
  
  Rack is the interface between the Ruby frameworks we know and love and the servers we are kinda _meh_ about. Designed by some guy (Ryan Allen) eons ago (2007), Rack has made its way into practically every Ruby framework. It has even made its way to the client side through projects like [Weary]() and Faraday. As Ian McDonald once said in the prosaic film Shawnshank Mountain Jurassic Park Redemption PT 3, "Rack finds a way". He was of course referring to birds but bird analogies apply eqaully well to everything from dinosaurs to Ruby framework APIs.
  
  At its core Rack is more interface than whatever is not interface. It defines what a web app is, how to communicate with it, and then gets out of the way.
  
  Rack defines an app as an object that responds to a `call` method, takes an environment hash as a parameter, and then returns an Array with three elements:
  
  - A HTTP response code
  - A hash of headers
  - And a response body (which must be an iterator)
  
  It's up to the web server to figure out how to serve the apps and provide them with an environment of data from the client. Rack itself doesn't touch any web server stuff. This allows Rack to remain minimal and easy to support, without sacrificing flexible.
  
  Most of Rack is helper code to make it easy for servers and apps to _implement_ the spec. Rack is the formal standard and the glue that allows web servers and apps to consistently talk to each other.
  
  <% note do %>
  
  This is not strictly true, Rack itself includes about a dozen server handlers in its core. That said, most modern webservers implement their own handlers.
  
  <% end %>
  
  In the darkest timeline, each ruby server implements its own protocol; and the frameworks _only_ work with certain servers, one must pick and choose what frameworks and servers to sacrifice to the Gods of interoperability.
  
  In the darkest timeline one cannot use all things together. This is the way it has always been in the land of "No Rack" and it is the way it it always will. Also there are dragons and factions and young adult rebel chosen ones.
  
  This "darkest timeline" is also known as Python. Just kidding Python guys, I greater than sign 3 you.
  
  
negative.code: Rack::Handler::WEBrick.run App.new
  ```
  
  Booting apps like this wouldn't work well in production. We can't easily swap out for a different webserver, we cant stack apps together, and managing the server process would be a pain.
  
  <% note do %>
  
  