Output cache - caches even with POST?

[eluser]markowe[/eluser]
As you probably know, CI's output cache function does a nice job of caching output into flat files on a per controller basis. As I understand it, the file name generated is an md5 of the uri string and the function looks for this on each page load, expiring it if necessary, or serving up the flat file if not, and a huge speed difference there is too.

But it does not take account of a form submission, i.e. user POST. For example, I have a page of product listings and the user can further filter the results by selecting form options (by date, by city, whatever), which are also optionally saved to a session cookie.

The output cache fuunction apparently does not take account of this and will serve up the same cached page regardless. What is the simple way round this?

[eluser]n0xie[/eluser]
Search operations (i.e. read operations) should probably use GET.

[eluser]markowe[/eluser]
Hmm, never thought about that... Get isn't really practical, I don't want a huge url string with, say 5 or 6 parameters on top of my existing ones. Suppose I could pack them into one url segment by doing a POST and then a GET from an intermediate page, that would solve the refresh problem too. Or do you mean actually reenabling native PHP GET? All seems a bit complicated, any thoughts?

[eluser]n0xie[/eluser]
Well the advantage of using GET for search is that you have unique url's per searchquery which will make caching work by default. Also you give people the option to link directly to a searchpage with filters in it.

For instance:

Code:

http://domain.tld/products/search?product=nokia&city=new york

This would give all the products related to Nokia in the New York area. This is both easily cachable and hotlinkable. You could add as many filters as you want. (date, city, whatever).

[eluser]markowe[/eluser]
Thanks for this input. Yes, when I was designing the application I took a conscious decision to not have ALL my parameters in the URL. Parameters which are purely user-specific I decided to store via POST/user session, like the city, state where they live etc. so the URL would not get too cluttered. I can see the SEO etc. benefits of doing it as above, but you are effectively advocating re-enabling GET, which CI has disabled, right?

With CI "segment" URLs, my link would end up looking like: controller/method/state/city/category/manufacturer/product/page and probably a few more, plus a marker like "Any" where they are not specified, so I could end up with:

products/listing/CA/Any/Any/phones/Nokia/E71/12

I dunno, those URLs get way too long and ugly, but I suppose I wouldn't be the first!

I guess the immediate way round my dilemma would be to write an intermediate page which checks for a POST and flushes the cache entry for that page (not catered for by the core, but I think someone wrote a small extension that does this) and then redirects to the actual page. Not too keen on redirects, but maybe this would be easiest...

[eluser]Phil Sturgeon[/eluser]
In this situation using a query string would be no help anyway. The output cache uses URI segments and URI segmnts alone. :-(

I ran across the same problems working on my REST library. Basically, don't use Output Cache library if you are making anything other than a really basic brochure/mostly static site.