NYCPHP Meetup

NYPHP.org

[nycphp-talk] PHP sessions on IE Mac

Chris Shiflett shiflett at php.net
Thu Mar 20 12:11:05 EST 2003


--- Nestor Florez <nestorflorez at earthlink.net> wrote:
> I can make a web session expire by using some php's session_destroy()
> function.  The purpose of this is so that if you log out and then you hit the
> BACK button, you will not be able to see previous data.  This works great on
> the PC with IE, MOZILLA, NETSCAPE.
> 
> When in the Mac World,  MOZILLA and NETSCAPE handled this the correct way,
> but IE and Safari still show you the previous data.

I can speculate as to where this discrepancy comes from, and it has little to
do with what you are doing and much to do with how the HTTP specification is
interpreted. 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."

Based on this, it is my opinion that IE and Safari on Mac are handling this
correctly. For any who are familiar with lynx, this has always been the case -
the back button shows you what you saw on the previous page rather than the
current state of that resource.

Most Web sites I have used where the information is considered extremely
sensitive state something like this upon logout:

"You have now been successfully logged out of the system. It is recommended
that you now close your browser to prevent access to any cached content."

Now, there is another bit of the specification that I believe causes the
discrepancy, because it seemingly conflicts with the above statement. 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."

You would have to check, but I would guess that this directive is used in your
application. My opinion is that the history mechanism in a browser is an
example of a non-shared cache and is exempt based on section 13.13. I think
other people's opinions vary in this regard, and I think this is the reason for
the discrepancies.

Chris

=====
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/



More information about the talk mailing list