NYCPHP Meetup

NYPHP.org

[nycphp-talk] back button, page timeout, sessions

Dan Cech dcech at phpwerx.net
Fri Jan 30 15:18:10 EST 2004


Chris Shiflett wrote:

> --- Dan Cech <dcech at phpwerx.net> wrote:
> 
>>I tend to use some cache control headers:
>>
>>Expires:·Fri,·30·Jan·2004·17:39:20·GMT
>>Cache-Control:·private,·no-store,·no-cache,·no-transform,
>>·must-revalidate
>>Cache-Control:·max-age=1,·s-maxage=1,·pre-check=1,·post-check=1
>>Pragma:·no-cache
> 
> I've seen this approach before by people who just want to eliminate
> caching altogether. That's not always best, and this question actually
> highlights one reason why. Using no-store is pretty absolute, although
> different browsers interpret this in different ways (see
> http://lists.nyphp.org/pipermail/talk/2003-March/002828.html). In general,
> it is better to understand the various directives for Cache-Control and
> use the ones most appropriate for your situation.

You can find the source for my header-generation functions at:

http://php.phpwerx.net/

The combination of different headers above should give the desired 
effect on the majority of browsers for web-application type situations, 
that is when you wish to always see a 'fresh' copy of a page.

>>Other than than I also use a per-form token to ensure that a given form 
>>cannot be submitted twice.
> 
> This can ensure that a form is not submitted twice (as well as help to
> protect against CSRF and similar attacks), but it doesn't help the "page
> has expired" problem that was originally asked. The most common approach
> is to use an intermediate page for processing, so that the POST request
> does not exist in the browser's history mechanism.

Fair enough, I do see what you mean in terms of the browser history. 
Here again it really depends on the type of application you are 
building, as to whether or not you want to allow the users to go 'back' 
to a previous page.

If this is desirable then the processing page approach has advantages, 
however if you are speaking in terms of a 'web application', you are 
just as well off avoiding the extra request cycle and using a 
token-based (or similar) system.

As usual the best solution is dependent on the exact problem you are 
trying to solve.

Dan





More information about the talk mailing list