[nycphp-talk] form posts, back button, IE page expired
bpang at bpang.com
Mon Aug 18 16:52:56 EDT 2003
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 bpang.com> 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
> (http://www.ietf.org/rfc/rfc2616.txt), 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,
> back button (history mechanism) should not ask the user to repost
> it should be displaying exactly what it did before. This is how lynx
> 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
> 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.
> Become a better Web developer with the HTTP Developer's Handbook
> talk mailing list
> talk at lists.nyphp.org
More information about the talk