NYCPHP Meetup

[Brian Pang]

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 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
statement:
> 
> "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
header
> that includes the no-store directive (unless you are controlling your
headers
> 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
request
> 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
likely
> that you might come to very different conclusions about how to implement a
> history mechanism. This might account for the discrepancies in
implementation.
> 
> Hope that helps.
> 
> Chris
> 
> =====
> Become a better Web developer with the HTTP Developer's Handbook
> http://httphandbook.org/
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
> 
>