1 files changed, 3 insertions, 3 deletions
diff --git a/railties/guides/source/caching_with_rails.textile b/railties/guides/source/caching_with_rails.textile
index 0bf9ca8887..6419d32c13 100644
--- a/railties/guides/source/caching_with_rails.textile
+++ b/railties/guides/source/caching_with_rails.textile
@@ -64,7 +64,7 @@ end
 
 If you want a more complicated expiration scheme, you can use cache sweepers to expire cached objects when things change. This is covered in the section on Sweepers.
 
-By default, page caching automatically gzips file (for example, to +products.html.gz+ if user requests +/products+) to reduce size of transmitted data (web servers are typically configured to use a moderate compression ratio as a compromise, but since precompilation happens once, compression ration is maximum).
+By default, page caching automatically gzips files (for example, to +products.html.gz+ if user requests +/products+) to reduce the size of data transmitted (web servers are typically configured to use a moderate compression ratio as a compromise, but since precompilation happens once, compression ratio is maximum).
 
 Nginx is able to serve compressed content directly from disk by enabling +gzip_static+:
 
@@ -77,13 +77,13 @@ location /  {
 You can disable gzipping by setting +:gzip+ option to false (for example, if action returns image):
 
 <ruby>
-    caches_page :image, :gzip => false
+caches_page :image, :gzip => false
 </ruby>
 
 Or, you can set custom gzip compression level (level names are taken from +Zlib+ constants):
 
 <ruby>
-    caches_page :image, :gzip => :best_speed
+caches_page :image, :gzip => :best_speed
 </ruby>
 
 NOTE: Page caching ignores all parameters. For example +/products?page=1+ will be written out to the filesystem as +products.html+ with no reference to the +page+ parameter. Thus, if someone requests +/products?page=2+ later, they will get the cached first page. A workaround for this limitation is to include the parameters in the page's path, e.g. +/productions/page/1+.