10 files changed, 181 insertions, 89 deletions
diff --git a/guides/source/active_record_querying.textile b/guides/source/active_record_querying.textile
index 8e23a577e2..c5755c8308 100644
--- a/guides/source/active_record_querying.textile
+++ b/guides/source/active_record_querying.textile
@@ -133,6 +133,24 @@ SELECT * FROM clients ORDER BY clients.id DESC LIMIT 1
 
 <tt>Model.last</tt> returns +nil+ if no matching record is found. No exception will be raised.
 
+h5. +find_by+
+
+<tt>Model.find_by</tt> finds the first record matching some conditions. For example:
+
+<ruby>
+Client.find_by first_name: 'Lifo'
+# => #<Client id: 1, first_name: "Lifo">
+
+Client.find_by first_name: 'Jon'
+# => nil
+</ruby>
+
+It is equivalent to writing:
+
+<ruby>
+Client.where(first_name: 'Lifo').first
+</ruby>
+
 h5(#first_1). +first!+
 
 <tt>Model.first!</tt> finds the first record. For example:
@@ -167,6 +185,24 @@ SELECT * FROM clients ORDER BY clients.id DESC LIMIT 1
 
 <tt>Model.last!</tt> raises +RecordNotFound+ if no matching record is found.
 
+h5(#find_by_1). +find_by!+
+
+<tt>Model.find_by!</tt> finds the first record matching some conditions. It raises +RecordNotFound+ if no matching record is found. For example:
+
+<ruby>
+Client.find_by! first_name: 'Lifo'
+# => #<Client id: 1, first_name: "Lifo">
+
+Client.find_by! first_name: 'Jon'
+# => RecordNotFound
+</ruby>
+
+It is equivalent to writing:
+
+<ruby>
+Client.where(first_name: 'Lifo').first!
+</ruby>
+
 h4. Retrieving Multiple Objects
 
 h5. Using Multiple Primary Keys
@@ -659,7 +695,7 @@ Optimistic locking allows multiple users to access the same record for edits, an
 
 <strong>Optimistic locking column</strong>
 
-In order to use optimistic locking, the table needs to have a column called +lock_version+. Each time the record is updated, Active Record increments the +lock_version+ column. If an update request is made with a lower value in the +lock_version+ field than is currently in the +lock_version+ column in the database, the update request will fail with an +ActiveRecord::StaleObjectError+. Example:
+In order to use optimistic locking, the table needs to have a column called +lock_version+ of type integer. Each time the record is updated, Active Record increments the +lock_version+ column. If an update request is made with a lower value in the +lock_version+ field than is currently in the +lock_version+ column in the database, the update request will fail with an +ActiveRecord::StaleObjectError+. Example:
 
 <ruby>
 c1 = Client.find(1)
@@ -943,21 +979,23 @@ If, in the case of this +includes+ query, there were no comments for any posts,
 
 h3. Scopes
 
-Scoping allows you to specify commonly-used ARel queries which can be referenced as method calls on the association objects or models. With these scopes, you can use every method previously covered such as +where+, +joins+ and +includes+. All scope methods will return an +ActiveRecord::Relation+ object which will allow for further methods (such as other scopes) to be called on it.
+Scoping allows you to specify commonly-used queries which can be referenced as method calls on the association objects or models. With these scopes, you can use every method previously covered such as +where+, +joins+ and +includes+. All scope methods will return an +ActiveRecord::Relation+ object which will allow for further methods (such as other scopes) to be called on it.
 
-To define a simple scope, we use the +scope+ method inside the class, passing the ARel query that we'd like run when this scope is called:
+To define a simple scope, we use the +scope+ method inside the class, passing the query that we'd like run when this scope is called:
 
 <ruby>
 class Post < ActiveRecord::Base
-  scope :published, where(:published => true)
+  scope :published, -> { where(published: true) }
 end
 </ruby>
 
-Just like before, these methods are also chainable:
+This is exactly the same as defining a class method, and which you use is a matter of personal preference:
 
 <ruby>
 class Post < ActiveRecord::Base
-  scope :published, where(:published => true).joins(:category)
+  def self.published
+    where(published: true)
+  end
 end
 </ruby>
 
@@ -965,8 +1003,8 @@ Scopes are also chainable within scopes:
 
 <ruby>
 class Post < ActiveRecord::Base
-  scope :published, where(:published => true)
-  scope :published_and_commented, published.and(self.arel_table[:comments_count].gt(0))
+  scope :published,               -> { where(:published => true) }
+  scope :published_and_commented, -> { published.and(self.arel_table[:comments_count].gt(0)) }
 end
 </ruby>
 
@@ -983,25 +1021,13 @@ category = Category.first
 category.posts.published # => [published posts belonging to this category]
 </ruby>
 
-h4. Working with times
-
-If you're working with dates or times within scopes, due to how they are evaluated, you will need to use a lambda so that the scope is evaluated every time.
-
-<ruby>
-class Post < ActiveRecord::Base
-  scope :created_before_now, lambda { where("created_at < ?", Time.zone.now ) }
-end
-</ruby>
-
-Without the +lambda+, this +Time.zone.now+ will only be called once.
-
 h4. Passing in arguments
 
-When a +lambda+ is used for a +scope+, it can take arguments:
+Your scope can take arguments:
 
 <ruby>
 class Post < ActiveRecord::Base
-  scope :created_before, lambda { |time| where("created_at < ?", time) }
+  scope :created_before, ->(time) { where("created_at < ?", time) }
 end
 </ruby>
 
@@ -1048,7 +1074,7 @@ If we wish for a scope to be applied across all queries to the model we can use
 
 <ruby>
 class Client < ActiveRecord::Base
-  default_scope where("removed_at IS NULL")
+  default_scope { where("removed_at IS NULL") }
 end
 </ruby>
 
diff --git a/guides/source/asset_pipeline.textile b/guides/source/asset_pipeline.textile
index a1b7a42d66..464788f30f 100644
--- a/guides/source/asset_pipeline.textile
+++ b/guides/source/asset_pipeline.textile
@@ -673,7 +673,7 @@ config.assets.compile = false
 # Generate digests for assets URLs.
 config.assets.digest = true
 
-# Defaults to Rails.root.join("public/assets")
+# Defaults to nil and saved in location specified by config.assets.prefix
 # config.assets.manifest = YOUR_PATH
 
 # Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
diff --git a/guides/source/configuring.textile b/guides/source/configuring.textile
index 246af587bc..717654d5d8 100644
--- a/guides/source/configuring.textile
+++ b/guides/source/configuring.textile
@@ -354,8 +354,7 @@ h4. Configuring Action Dispatch
 
 h4. Configuring Action View
 
-There are only a few configuration options for Action View, starting with six on +ActionView::Base+:
-
+<tt>config.action_view</tt> includes a small number of configuration settings:
 
 * +config.action_view.field_error_proc+ provides an HTML generator for displaying errors that come from Active Record. The default is
 
@@ -397,6 +396,14 @@ And can reference in the view with the following code:
 
 * +config.action_view.embed_authenticity_token_in_remote_forms+ allows you to set the default behavior for +authenticity_token+ in forms with +:remote => true+. By default it's set to false, which means that remote forms will not include +authenticity_token+, which is helpful when you're fragment-caching the form. Remote forms get the authenticity from the +meta+ tag, so embedding is unnecessary unless you support browsers without JavaScript. In such case you can either pass +:authenticity_token => true+ as a form option or set this config setting to +true+
 
+* +config.action_view.prefix_partial_path_with_controller_namespace+ determines whether or not partials are looked up from a subdirectory in templates rendered from namespaced controllers. For example, consider a controller named +Admin::PostsController+ which renders this template:
+
+<erb>
+<%= render @post %>
+<erb>
+
+The default setting is +true+, which uses the partial at +/admin/posts/_post.erb+. Setting the value to +false+ would render +/posts/_post.erb+, which is the same behavior as rendering from a non-namespaced controller such as +PostsController+.
+
 h4. Configuring Action Mailer
 
 There are a number of settings available on +config.action_mailer+:
diff --git a/guides/source/engines.textile b/guides/source/engines.textile
index 047f9afd76..36210aedb0 100644
--- a/guides/source/engines.textile
+++ b/guides/source/engines.textile
@@ -16,7 +16,7 @@ Engines can be considered miniature applications that provide functionality to t
 
 Therefore, engines and applications can be thought of almost the same thing, just with very minor differences, as you'll see throughout this guide. Engines and applications also share a common structure.
 
-Engines are also closely related to plugins where the two share a common +lib+ directory structure and are both generated using the +rails plugin new+ generator. The difference being that an engine is considered a "full plugin" by Rails -- as indicated by the +--full+ option that's passed to the generator command -- but this guide will refer to them simply as "engines" throughout. An engine *can* be a plugin, and a plugin *can* be an engine.
+Engines are also closely related to plugins where the two share a common +lib+ directory structure and are both generated using the +rails plugin new+ generator. The difference being that an engine is considered a "full plugin" by Rails as indicated by the +--full+ option that's passed to the generator command, but this guide will refer to them simply as "engines" throughout. An engine *can* be a plugin, and a plugin *can* be an engine.
 
 The engine that will be created in this guide will be called "blorgh". The engine will provide blogging functionality to its host applications, allowing for new posts and comments to be created. At the beginning of this guide, you will be working solely within the engine itself, but in later sections you'll see how to hook it into an application.
 
@@ -51,7 +51,7 @@ h5. Critical files
 At the root of this brand new engine's directory, lives a +blorgh.gemspec+ file. When you include the engine into the application later on, you will do so with this line in a Rails application's +Gemfile+:
 
 <ruby>
-  gem 'blorgh', :path => "vendor/engines/blorgh"
+gem 'blorgh', :path => "vendor/engines/blorgh"
 </ruby>
 
 By specifying it as a gem within the +Gemfile+, Bundler will load it as such, parsing this +blorgh.gemspec+ file and requiring a file within the +lib+ directory called +lib/blorgh.rb+. This file requires the +blorgh/engine.rb+ file (located at +lib/blorgh/engine.rb+) and defines a base module called +Blorgh+.
@@ -77,7 +77,7 @@ end
 
 By inheriting from the +Rails::Engine+ class, this gem notifies Rails that there's an engine at the specified path, and will correctly mount the engine inside the application, performing tasks such as adding the +app+ directory of the engine to the load path for models, mailers, controllers and views.
 
-The +isolate_namespace+ method here deserves special notice. This call is responsible for isolating the controllers, models, routes and other things into their own namespace, away from similar components inside hte application. Without this, there is a possibility that the engine's components could "leak" into the application, causing unwanted disruption, or that important engine components could be overriden by similarly named things within the application. One of the examples of such conflicts are helpers. Without calling +isolate_namespace+, engine's helpers would be included in application's controllers.
+The +isolate_namespace+ method here deserves special notice. This call is responsible for isolating the controllers, models, routes and other things into their own namespace, away from similar components inside the application. Without this, there is a possibility that the engine's components could "leak" into the application, causing unwanted disruption, or that important engine components could be overridden by similarly named things within the application. One of the examples of such conflicts are helpers. Without calling +isolate_namespace+, engine's helpers would be included in application's controllers.
 
 NOTE: It is *highly* recommended that the +isolate_namespace+ line be left within the +Engine+ class definition. Without it, classes generated in an engine *may* conflict with an application.
 
@@ -115,7 +115,6 @@ The +test+ directory is where tests for the engine will go. To test the engine,
 
 <ruby>
 Rails.application.routes.draw do
-
   mount Blorgh::Engine => "/blorgh"
 end
 </ruby>
@@ -126,7 +125,7 @@ Also in the test directory is the +test/integration+ directory, where integratio
 
 h3. Providing engine functionality
 
-The engine that this guide covers will provide posting and commenting functionality and follows a similar thread to the "Getting Started Guide":getting-started.html, with some new twists.
+The engine that this guide covers will provide posting and commenting functionality and follows a similar thread to the "Getting Started Guide":getting_started.html, with some new twists.
 
 h4. Generating a post resource
 
@@ -179,7 +178,6 @@ After that, a line for the resource is inserted into the +config/routes.rb+ file
 <ruby>
 Blorgh::Engine.routes.draw do
   resources :posts
-
 end
 </ruby>
 
@@ -219,17 +217,13 @@ By default, the scaffold styling is not applied to the engine as the engine's la
 <%= stylesheet_link_tag "scaffold" %>
 </erb>
 
-You can see what the engine has so far by running +rake db:migrate+ at the root of our engine to run the migration generated by the scaffold generator, and then running +rails server+ in +test/dummy+. When you open +http://localhost:3000/blorgh/posts+ you will see the default scaffold that has been generated.
-
-!images/engines_scaffold.png(Blank engine scaffold)!
-
-Click around! You've just generated your first engine's first functions.
+You can see what the engine has so far by running +rake db:migrate+ at the root of our engine to run the migration generated by the scaffold generator, and then running +rails server+ in +test/dummy+. When you open +http://localhost:3000/blorgh/posts+ you will see the default scaffold that has been generated. Click around! You've just generated your first engine's first functions.
 
 If you'd rather play around in the console, +rails console+ will also work just like a Rails application. Remember: the +Post+ model is namespaced, so to reference it you must call it as +Blorgh::Post+.
 
 <ruby>
-  >> Blorgh::Post.find(1)
-  => #<Blorgh::Post id: 1 ...>
+>> Blorgh::Post.find(1)
+=> #<Blorgh::Post id: 1 ...>
 </ruby>
 
 One final thing is that the +posts+ resource for this engine should be the root of the engine. Whenever someone goes to the root path where the engine is mounted, they should be shown a list of posts. This can be made to happen if this line is inserted into the +config/routes.rb+ file inside the engine:
@@ -355,11 +349,11 @@ end
 
 This is the final part required to get the new comment form working. Displaying the comments however, is not quite right yet. If you were to create a comment right now you would see this error:
 
-<text>
-  Missing partial blorgh/comments/comment with {:handlers=>[:erb, :builder], :formats=>[:html], :locale=>[:en, :en]}. Searched in:
-    * "/Users/ryan/Sites/side_projects/blorgh/test/dummy/app/views"
-    * "/Users/ryan/Sites/side_projects/blorgh/app/views"
-</text>
+<plain>
+Missing partial blorgh/comments/comment with {:handlers=>[:erb, :builder], :formats=>[:html], :locale=>[:en, :en]}. Searched in:
+  * "/Users/ryan/Sites/side_projects/blorgh/test/dummy/app/views"
+  * "/Users/ryan/Sites/side_projects/blorgh/app/views"
+</plain>
 
 The engine is unable to find the partial required for rendering the comments. Rails has looked firstly in the application's (+test/dummy+) +app/views+ directory and then in the engine's +app/views+ directory. When it can't find it, it will throw this error. The engine knows to look for +blorgh/comments/comment+ because the model object it is receiving is from the +Blorgh::Comment+ class.
 
@@ -511,11 +505,11 @@ $ rake blorgh:install:migrations
 
 Notice here that only _one_ migration was copied over here. This is because the first two migrations were copied over the first time this command was run.
 
-<shell>
-  NOTE: Migration [timestamp]_create_blorgh_posts.rb from blorgh has been skipped. Migration with the same name already exists.
-  NOTE: Migration [timestamp]_create_blorgh_comments.rb from blorgh has been skipped. Migration with the same name already exists.
-  Copied migration [timestamp]_add_author_id_to_blorgh_posts.rb from blorgh
-</shell>
+<plain>
+NOTE Migration [timestamp]_create_blorgh_posts.rb from blorgh has been skipped. Migration with the same name already exists.
+NOTE Migration [timestamp]_create_blorgh_comments.rb from blorgh has been skipped. Migration with the same name already exists.
+Copied migration [timestamp]_add_author_id_to_blorgh_posts.rb from blorgh
+</plain>
 
 Run this migration using this command:
 
@@ -536,9 +530,9 @@ Finally, the author's name should be displayed on the post's page. Add this code
 
 By outputting +@post.author+ using the +<%=+ tag the +to_s+ method will be called on the object. By default, this will look quite ugly:
 
-<text>
+<plain>
 #<User:0x00000100ccb3b0>
-</text>
+</plain>
 
 This is undesirable and it would be much better to have the user's name there. To do this, add a +to_s+ method to the +User+ class within the application:
 
@@ -581,9 +575,9 @@ self.author = Blorgh.user_class.constantize.find_or_create_by_name(author_name)
 To save having to call +constantize+ on the +user_class+ result all the time, you could instead just override the +user_class+ getter method inside the +Blorgh+ module in the +lib/blorgh.rb+ file to always call +constantize+ on the saved value before returning the result:
 
 <ruby>
-  def self.user_class
-    @@user_class.constantize
-  end
+def self.user_class
+  @@user_class.constantize
+end
 </ruby>
 
 This would then turn the above code for +self.author=+ into this:
@@ -663,10 +657,6 @@ Try this now by creating a new file at +app/views/blorgh/posts/index.html.erb+ a
 <% end %>
 </erb>
 
-Rather than looking like the default scaffold, the page will now look like this:
-
-!images/engines_post_override.png(Engine scaffold overriden)!
-
 h4. Routes
 
 Routes inside an engine are, by default, isolated from the application. This is done by the +isolate_namespace+ call inside the +Engine+ class. This essentially means that the application and its engines can have identically named routes, and that they will not clash.
@@ -674,9 +664,9 @@ Routes inside an engine are, by default, isolated from the application. This is
 Routes inside an engine are drawn on the +Engine+ class within +config/routes.rb+, like this:
 
 <ruby>
-  Blorgh::Engine.routes.draw do
-    resources :posts
-  end
+Blorgh::Engine.routes.draw do
+  resources :posts
+end
 </ruby>
 
 By having isolated routes such as this, if you wish to link to an area of an engine from within an application, you will need to use the engine's routing proxy method. Calls to normal routing methods such as +posts_path+ may end up going to undesired locations if both the application and the engine both have such a helper defined.
@@ -717,11 +707,11 @@ Imagine that you did have an asset located at +app/assets/stylesheets/blorgh/sty
 
 You can also specify these assets as dependencies of other assets using the Asset Pipeline require statements in processed files:
 
-<css>
+<plain>
 /*
  *= require blorgh/style
 */
-</css>
+</plain>
 
 h4. Separate Assets & Precompiling
 
@@ -736,7 +726,7 @@ You can define assets for precompilation in +engine.rb+
 initializer do |app|
   app.config.assets.precompile += %w(admin.css admin.js)
 end
-</ruby
+</ruby>
 
 For more information, read the "Asset Pipeline guide":http://guides.rubyonrails.org/asset_pipeline.html
 
diff --git a/guides/source/getting_started.textile b/guides/source/getting_started.textile
index 0a85c84155..d12606c5de 100644
--- a/guides/source/getting_started.textile
+++ b/guides/source/getting_started.textile
@@ -152,11 +152,11 @@ $ rails server
 
 TIP: Compiling CoffeeScript to JavaScript requires a JavaScript runtime and the absence of a runtime will give you an +execjs+ error. Usually Mac OS X and Windows come with a JavaScript runtime installed. Rails adds the +therubyracer+ gem to Gemfile in a commented line for new apps and you can uncomment if you need it. +therubyrhino+ is the recommended runtime for JRuby users and is added by default to Gemfile in apps generated under JRuby. You can investigate about all the supported runtimes at "ExecJS":https://github.com/sstephenson/execjs#readme.
 
-This will fire up an instance of a webserver built into Ruby called WEBrick by default. To see your application in action, open a browser window and navigate to "http://localhost:3000":http://localhost:3000. You should see Rails' default information page:
+This will fire up an instance of a webserver built into Ruby called WEBrick by default. To see your application in action, open a browser window and navigate to "http://localhost:3000":http://localhost:3000. You should see the Rails default information page:
 
 !images/rails_welcome.png(Welcome Aboard screenshot)!
 
-TIP: To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to stop the server; changes you make in files will be automatically picked up by the server.
+TIP: To stop the web server, hit Ctrl+C in the terminal window where it's running. In development mode, Rails does not generally require you to restart the server; changes you make in files will be automatically picked up by the server.
 
 The "Welcome Aboard" page is the _smoke test_ for a new Rails application: it makes sure that you have your software configured correctly enough to serve a page. You can also click on the _About your application’s environment_ link to see a summary of your application's environment.
 
diff --git a/guides/source/layouts_and_rendering.textile b/guides/source/layouts_and_rendering.textile
index 4b4f9f3745..7c7fc7044c 100644
--- a/guides/source/layouts_and_rendering.textile
+++ b/guides/source/layouts_and_rendering.textile
@@ -1134,13 +1134,6 @@ In Rails 3.0, there is also a shorthand for this. Assuming +@products+ is a coll
 
 Rails determines the name of the partial to use by looking at the model name in the collection. In fact, you can even create a heterogeneous collection and render it this way, and Rails will choose the proper partial for each member of the collection:
 
-In the event that the collection is empty, +render+ will return nil, so it should be fairly simple to provide alternative content.
-
-<erb>
-<h1>Products</h1>
-<%= render(@products) || 'There are no products available.' %>
-</erb>
-
 * +index.html.erb+
 
 <erb>
@@ -1162,6 +1155,13 @@ In the event that the collection is empty, +render+ will return nil, so it shoul
 
 In this case, Rails will use the customer or employee partials as appropriate for each member of the collection.
 
+In the event that the collection is empty, +render+ will return nil, so it should be fairly simple to provide alternative content.
+
+<erb>
+<h1>Products</h1>
+<%= render(@products) || 'There are no products available.' %>
+</erb>
+
 h5. Local Variables
 
 To use a custom local variable name within the partial, specify the +:as+ option in the call to the partial:
diff --git a/guides/source/migrations.textile b/guides/source/migrations.textile
index c11f8e221b..cb7ee1e6a2 100644
--- a/guides/source/migrations.textile
+++ b/guides/source/migrations.textile
@@ -497,7 +497,7 @@ and
 h4. Using the +change+ Method
 
 The +change+ method removes the need to write both +up+ and +down+ methods in
-those cases that Rails know how to revert the changes automatically. Currently,
+those cases that Rails knows how to revert the changes automatically. Currently,
 the +change+ method supports only these migration definitions:
 
 * +add_column+
diff --git a/guides/source/rails_on_rack.textile b/guides/source/rails_on_rack.textile
index 9526526bc7..73e0f242cc 100644
--- a/guides/source/rails_on_rack.textile
+++ b/guides/source/rails_on_rack.textile
@@ -91,13 +91,15 @@ For a freshly generated Rails application, this might produce something like:
 <ruby>
 use ActionDispatch::Static
 use Rack::Lock
-use ActiveSupport::Cache::Strategy::LocalCache
+use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x000000029a0838>
 use Rack::Runtime
+use Rack::MethodOverride
+use ActionDispatch::RequestId
 use Rails::Rack::Logger
 use ActionDispatch::ShowExceptions
 use ActionDispatch::DebugExceptions
 use ActionDispatch::RemoteIp
-use Rack::Sendfile
+use ActionDispatch::Reloader
 use ActionDispatch::Callbacks
 use ActiveRecord::ConnectionAdapters::ConnectionManagement
 use ActiveRecord::QueryCache
@@ -105,8 +107,9 @@ use ActionDispatch::Cookies
 use ActionDispatch::Session::CookieStore
 use ActionDispatch::Flash
 use ActionDispatch::ParamsParser
-use Rack::MethodOverride
 use ActionDispatch::Head
+use Rack::ConditionalGet
+use Rack::ETag
 use ActionDispatch::BestStandardsSupport
 run Blog::Application.routes
 </ruby>
@@ -161,18 +164,73 @@ config.middleware.delete(middleware)
 
 h4. Internal Middleware Stack
 
-Much of Action Controller's functionality is implemented as Middlewares. The following table explains the purpose of each of them:
+Much of Action Controller's functionality is implemented as Middlewares. The following list explains the purpose of each of them:
 
-|_.Middleware|_.Purpose|
-|+Rack::Lock+|Sets <tt>env["rack.multithread"]</tt> flag to +true+ and wraps the application within a Mutex.|
-|+ActionController::Failsafe+|Returns HTTP Status +500+ to the client if an exception gets raised while dispatching.|
-|+ActiveRecord::QueryCache+|Enables the Active Record query cache.|
-|+ActionDispatch::Session::CookieStore+|Uses the cookie based session store.|
-|+ActionDispatch::Session::CacheStore+|Uses the Rails cache based session store.|
-|+ActionDispatch::Session::MemCacheStore+|Uses the memcached based session store.|
-|+ActiveRecord::SessionStore+|Uses the database based session store.|
-|+Rack::MethodOverride+|Sets HTTP method based on +_method+ parameter or <tt>env["HTTP_X_HTTP_METHOD_OVERRIDE"]</tt>.|
-|+Rack::Head+|Discards the response body if the client sends a +HEAD+ request.|
+ *+ActionDispatch::Static+*
+* Used to serve static assets. Disabled if <tt>config.serve_static_assets</tt> is true.
+
+ *+Rack::Lock+*
+* Sets <tt>env["rack.multithread"]</tt> flag to +true+ and wraps the application within a Mutex.
+
+ *+ActiveSupport::Cache::Strategy::LocalCache::Middleware+*
+* Used for memory caching. This cache is not thread safe.
+
+ *+Rack::Runtime+*
+* Sets an X-Runtime header, containing the time (in seconds) taken to execute the request.
+
+ *+Rack::MethodOverride+*
+* Allows the method to be overridden if <tt>params[:_method]</tt> is set. This is the middleware which supports the PUT and DELETE HTTP method types.
+
+ *+ActionDispatch::RequestId+*
+* Makes a unique +X-Request-Id+ header available to the response and enables the <tt>ActionDispatch::Request#uuid</tt> method.
+
+ *+Rails::Rack::Logger+*
+* Notifies the logs that the request has began. After request is complete, flushes all the logs.
+
+ *+ActionDispatch::ShowExceptions+*
+* Rescues any exception returned by the application and calls an exceptions app that will wrap it in a format for the end user.
+
+ *+ActionDispatch::DebugExceptions+*
+* Responsible for logging exceptions and showing a debugging page in case the request is local.
+
+ *+ActionDispatch::RemoteIp+*
+* Checks for IP spoofing attacks.
+
+ *+ActionDispatch::Reloader+*
+* Provides prepare and cleanup callbacks, intended to assist with code reloading during development.
+
+ *+ActionDispatch::Callbacks+*
+* Runs the prepare callbacks before serving the request.
+
+ *+ActiveRecord::ConnectionAdapters::ConnectionManagement+*
+* Cleans active connections after each request, unless the <tt>rack.test</tt> key in the request environment is set to +true+.
+
+ *+ActiveRecord::QueryCache+*
+* Enables the Active Record query cache.
+
+ *+ActionDispatch::Cookies+*
+* Sets cookies for the request.
+
+ *+ActionDispatch::Session::CookieStore+*
+* Responsible for storing the session in cookies.
+
+ *+ActionDispatch::Flash+*
+* Sets up the flash keys. Only available if <tt>config.action_controller.session_store</tt> is set to a value.
+
+ *+ActionDispatch::ParamsParser+*
+* Parses out parameters from the request into <tt>params</tt>.
+
+ *+ActionDispatch::Head+*
+* Converts HEAD requests to +GET+ requests and serves them as so.
+
+ *+Rack::ConditionalGet+*
+* Adds support for "Conditional +GET+" so that server responds with nothing if page wasn't changed.
+
+ *+Rack::ETag+*
+* Adds ETag header on all String bodies. ETags are used to validate cache.
+
+ *+ActionDispatch::BestStandardsSupport+*
+* Enables “best standards support” so that IE8 renders some elements correctly.
 
 TIP: It's possible to use any of the above middlewares in your custom Rack stack.
 
diff --git a/guides/source/routing.textile b/guides/source/routing.textile
index e93b1280e0..75f4e82918 100644
--- a/guides/source/routing.textile
+++ b/guides/source/routing.textile
@@ -535,6 +535,17 @@ TwitterClone::Application.routes.draw do
 end
 </ruby>
 
+You can also specify constraints as a lambda:
+
+<ruby>
+TwitterClone::Application.routes.draw do
+  match "*path" => "blacklist#index",
+    :constraints => lambda { |request| Blacklist.retrieve_ips.include?(request.remote_ip) }
+end
+</ruby>
+
+Both the +matches?+ method and the lambda gets the +request+ object as an argument.
+
 h4. Route Globbing
 
 Route globbing is a way to specify that a particular parameter should be matched to all the remaining parts of a route. For example
diff --git a/guides/source/testing.textile b/guides/source/testing.textile
index 60b0aa89b9..d35be6a70e 100644
--- a/guides/source/testing.textile
+++ b/guides/source/testing.textile
@@ -412,7 +412,7 @@ NOTE: +assert_valid(record)+ has been deprecated. Please use +assert(record.vali
 |+assert_no_difference(expressions, message = nil, &amp;block)+                     |Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.|
 |+assert_recognizes(expected_options, path, extras={}, message=nil)+                |Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.|
 |+assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)+  |Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.|
-|+assert_response(type, message = nil)+                                             |Asserts that the response comes with a specific status code. You can specify +:success+ to indicate 200,  +:redirect+ to indicate 300-399, +:missing+ to indicate 404, or +:error+ to match the 500-599 range|
+|+assert_response(type, message = nil)+                                             |Asserts that the response comes with a specific status code. You can specify +:success+ to indicate 200-299,  +:redirect+ to indicate 300-399, +:missing+ to indicate 404, or +:error+ to match the 500-599 range|
 |+assert_redirected_to(options = {}, message=nil)+                                  |Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that +assert_redirected_to(:controller => "weblog")+ will also match the redirection of +redirect_to(:controller => "weblog", :action => "show")+ and so on.|
 |+assert_template(expected = nil, message=nil)+                                     |Asserts that the request was rendered with the appropriate template file.|