Full page caching with post request
Permalink
I have some custom blocks that can accept post/get requests. I'm using the following cache variables:
protected $btCacheBlockRecord = true;
protected $btCacheBlockOutput = true;
protected $btCacheBlockOutputOnPost = false;
protected $btCacheBlockOutputForRegisteredUsers = true;
When full page caching is enabled ("if all blocks support it"), it ignores the "cache on post" setting and returns the cache even when post variables are used. I need full page cache to be used when there are no post/get requests and not use the cache when there are requests. Am I doing something wrong?
protected $btCacheBlockRecord = true;
protected $btCacheBlockOutput = true;
protected $btCacheBlockOutputOnPost = false;
protected $btCacheBlockOutputForRegisteredUsers = true;
When full page caching is enabled ("if all blocks support it"), it ignores the "cache on post" setting and returns the cache even when post variables are used. I need full page cache to be used when there are no post/get requests and not use the cache when there are requests. Am I doing something wrong?
Are you logged in while testing. The $btCacheBlockOutputForRegisteredUsers variable might play a roll in this.
Thanks for your reply.
I've been sure to test this using private windows to avoid that possibility, and the same behavior occurs in Firefox and IE10.
I've attached a very simple block that exhibits the behavior. This block actually shows a more serious problem than I realized earlier -- if the full-page isn't cached yet, and you include a query string in the url, then the result of that will get cached in the full-page.
step-by-step instructions to duplicate:
First, install the test_cachpost block on a page where no other blocks will prevent full-page caching. For the purpose of this, I'll assume it's installed at /test/.
Also, I recommend having 2 windows open: one in a private window not logged in to perform the tests and another that is logged in so that you can verify if full-page caching is enabled (and to perform clear cache, etc.)
1) Verify that the page isn't already cached. I've been doing a full-site "clear cache" and also clearing my browser's cache. Purging just the page doesn't seem to clear the block's cache.
2) Visit the page with the following query:
/test/?g=gettest
Result: you should see 'GET: gettest' displayed; if you verify the full-page caching, it should be enabled
3) Visit the page without any query:
/test/
(reload the page to make sure your browser isn't caching)
Result: 'GET: gettest' is still displayed
4) type something into the text box and press submit
Result: 'GET: gettest' is still displayed (it should display 'POST: YourTextHere')
Test2:
1) Clear cache and browser's cache
2) Visit the page without any queries:
/test/
Result: "no query found" is displayed
3) Verify that the full-page has cached
4) Type something into the text box and submit
Result: "no query found" is still displayed
Test3:
The only way it works as one would expect:
1) Visit the page
2) Clear the cache
3) Type something into the text box and submit
Result: works as expected and full-page is not cached
I've been sure to test this using private windows to avoid that possibility, and the same behavior occurs in Firefox and IE10.
I've attached a very simple block that exhibits the behavior. This block actually shows a more serious problem than I realized earlier -- if the full-page isn't cached yet, and you include a query string in the url, then the result of that will get cached in the full-page.
step-by-step instructions to duplicate:
First, install the test_cachpost block on a page where no other blocks will prevent full-page caching. For the purpose of this, I'll assume it's installed at /test/.
Also, I recommend having 2 windows open: one in a private window not logged in to perform the tests and another that is logged in so that you can verify if full-page caching is enabled (and to perform clear cache, etc.)
1) Verify that the page isn't already cached. I've been doing a full-site "clear cache" and also clearing my browser's cache. Purging just the page doesn't seem to clear the block's cache.
2) Visit the page with the following query:
/test/?g=gettest
Result: you should see 'GET: gettest' displayed; if you verify the full-page caching, it should be enabled
3) Visit the page without any query:
/test/
(reload the page to make sure your browser isn't caching)
Result: 'GET: gettest' is still displayed
4) type something into the text box and press submit
Result: 'GET: gettest' is still displayed (it should display 'POST: YourTextHere')
Test2:
1) Clear cache and browser's cache
2) Visit the page without any queries:
/test/
Result: "no query found" is displayed
3) Verify that the full-page has cached
4) Type something into the text box and submit
Result: "no query found" is still displayed
Test3:
The only way it works as one would expect:
1) Visit the page
2) Clear the cache
3) Type something into the text box and submit
Result: works as expected and full-page is not cached
I still see this in concrete5 v8. Two issues have been added for this:
https://github.com/concrete5/concrete5/issues/5713... and
https://github.com/concrete5/concrete5/issues/5714...
https://github.com/concrete5/concrete5/issues/5713... and
https://github.com/concrete5/concrete5/issues/5714...
- if the full-page isn't already cached, then using POST seems to work as advertised (and the full page won't cache)
- if you visit the page without any POST, then it will cache the full-page, which is fine by itself
- once the full-page is cached, further attempts to use POST will return the full-page cache (304 Not Modified) -- this is not acceptable
Furthermore, using a GET parameter doesn't seem to work at all -- it just ignores the GET params. For some reason, it does not cache the full-page.
I would expect to get a 304 result if there is no POST/GET query for the request, but it should not use the full-page cache if a POST/GET is used.
Is this a known issue? Will it be fixed in the next release? Is the current recommendation for blocks that need queries to disable caching?