anchor.diff:  
   # Responses
   
  -The existence of Rack::Response is an enigma. After all, aren't our responses just an array? What good would a wrapper object do when we have to return an array? The secret is that we only have to return something that acts like an array. If we provide a `to_a` method we can return an object instead of an array.
  +The existence of Rack::Response is an enigma. After all, aren't our responses just an array? What good would a response object do when we have to return an array? The secret is that we only have to return something that _acts_ like an array. If we provide a `to_a` method we can return an object instead of an array.
   
  -We can construct a valid response class like this:
  +We can construct a valid response object like this:
   
   ```ruby
   class Response
  
positive.code: @response
  ```
  
  This hides a secret, Cookies are just headers and we could do the same thing with:
  
  ```ruby
  @response = Rack::Response.new('Wow!')
  
negative.code: @response
  ```
  
  Chances are though that we would have formatted our cookie improperly; most of us have no idea how a cookie looks, have heard of RFC 822 or even know what RFC is. set_cookie makes everything look and feel like a hash -- and we work with hashes everyday. The real world is a mess -- thank your Rack you don't have to deal with it.
  
  Everything in our response is just headers. When we use those fancy methods they are just making it easier to set headers. Take "`redirect()``" for example, it simply sets a 302 status code and a `Location` header. All of it, just headers.
  
  At their core requests and responses are both merely wrapper objects. They give us a nice API to work with instead of forcing us to manipulate things manually. They are easy to extend and build upon just like Rack apps. If we wanted to we could use these simple patterns to build an entire MVC app without any framework.
  