From 650ec898e5f4668b63925d05f8b722a5226a79dd Mon Sep 17 00:00:00 2001
From: Cheah Chu Yeow <chuyeow@gmail.com>
Date: Sun, 13 Nov 2011 13:25:39 +0800
Subject: Suggest a workaround for page caching and parameters instead of an
 unhelpful warning.

---
 railties/guides/source/caching_with_rails.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/caching_with_rails.textile')

diff --git a/railties/guides/source/caching_with_rails.textile b/railties/guides/source/caching_with_rails.textile
index 5bf2284230..972579b453 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.
 
-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. Be careful when page caching GET parameters in the URL!
+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+.
 
 INFO: Page caching runs in an after filter. Thus, invalid requests won't generate spurious cache entries as long as you halt them. Typically, a redirection in some before filter that checks request preconditions does the job.
 
-- 
cgit v1.2.3

