[nycphp-talk] form posts, back button, IE page expired

Brian Pang bpang at
Mon Aug 18 16:52:56 EDT 2003

thanks, Chris..

I used set_cache_limiter('private')... I think it is working the way I
want it to.

The history mechanism is fine, with no resubmission/post of data.

All I really about care in this case is getting my client off my back
about the Warning Page Expired page. :-D

your detailed information is still appreciated and will be helpful in
the future when I care more about the data's shelf-life

> --- Brian Pang <bpang at> wrote:
> > How do you guys/gals deal with the IE Page Expired page which is
> > generated if you use the back button to return to a page which had
> > form POST information in it originally?
> To answer your immediate question, you can do either of the following:
> 1. Allow caching
> 2. Use an intermediate URL for processing
> To explain why browsers seem to behave differently, read on...
> If you will look at section 13.13 of RFC 2616
> (, you will see the following
> "In particular history mechanisms SHOULD NOT try to show a semantically
> transparent view of the current state of a resource. Rather, a history
> mechanism is meant to show exactly what the user saw at the time when the
> resource was retrieved."
> It sounds like whether you allow caching should make no difference,
right? The
> back button (history mechanism) should not ask the user to repost
data, because
> it should be displaying exactly what it did before. This is how lynx
works, if
> you're familiar with using it.
> In most cases, your PHP applications are going to send a Cache-Control
> that includes the no-store directive (unless you are controlling your
> more specifically than most developers). In section 14.9.2, the no-store
> directive of the Cache-Control header is explained:
> "If sent in a request, a cache MUST NOT store any part of either this
> or any response to it. If sent in a response, a cache MUST NOT store
any part
> of either this response or the request that elicited it."
> Thus, depending on how your interpret these statements, it seems quite
> that you might come to very different conclusions about how to implement a
> history mechanism. This might account for the discrepancies in
> Hope that helps.
> Chris
> =====
> Become a better Web developer with the HTTP Developer's Handbook
> _______________________________________________
> talk mailing list
> talk at

More information about the talk mailing list