asked on

private browser cache for web form over SSL

I have a web form hosted over SSL using php and sessions (page1). I want to be able to POST to page2 then return (via back button) to page1 and still retain the original data in the form fields. I used to be able to achieve this effect by simply adding the following headers to page1:

header("Expires: Sat, 01 Jan 2000 00:00:00 GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: post-check=0, pre-check=0",false);
session_cache_limiter("private, must-revalidate");
session_start();

However, after upgrading server to php 5 and re-installing apache, this does not work for me anymore (returning to page 1 gives me empty form fields). Not sure why. Is the browser unable to satisfy request to cache privately b/c of the nature of ssl?

Understand I could store posted data in a session then re-populate fields accordingly, however, would be much easier to just add a few header lines, as with previous approach.

Does anyone know the appropriates headers to enable private-cache with php (using sessions) over SSL? Thanks.

note: I am not sure if manipulating headers (to cache content privately, on client) poses much of a security risk. Would assume since both page1 and page2 are hosted over SSL, the transfer of the viewer data is secure (and although the private browser cache may pose minor security threat - it's probably not much different than storing as php session on server). I'm not posting overly sensitive data (no credit card info, just email/name/address), but still want it to be secure.

jongenant

ASKER

Hi. Anyone have any advice?

Regards,
Jon

btw. increasing point value of question

mattjp88

as far as I know, having field pre-filled in with data when using the back button is a browser specific feature. setting the expiry may work, as you tried, although you may want to try putting it in a meta header int he HTML.

http://www.htmlhelp.com/reference/wilbur/head/meta.html

even trying to repopulate the fields from session data when the page loads probably wont work because the page is being pulled from cache, instead of being reloaded. Try the meta approach.

-Matt

Roonaan

Jongenant,

I agree with mattjp88 that this is a browser-specific feature. The only workaround I see would be to indeed prefill the fields with the data in your session and then send NO-cache headers rather than cache-headers.

-r-

jongenant

ASKER

Hi mattjp88 and Roonaan,

Thanks for the replies. Appreciate it. I guess what confused me most is why this was working fine over past year and half, then once I upgraded to php 5 (and upgraded apache as well) that it would stop working. That lead me to think that it could be a php 5 (vs. 4) thing. But understand that the private cache feature is browser-dependent/specific. (Maybe I had upgraded my browser during this time... and maybe was an i.e. flaw to begin w/)

I tried the Expires, HTTP Header approach as mentioned by mattjp88 (setting expires date to a future date), but this didn't help. And looking at the old php headers I was using, specifically, 'header("Expires: Sat, 01 Jan 2000 00:00:00 GMT");' would think this is actually incorrect b/c this date is less than current (thus, should expire, and not cache), guess the other header/session directives took presedence.

When the page is not served over SSL (just http://), the browser will cache privately, with php's, ' header("Cache-control: private"); '.

But essentially, a private browser cache over SLL is not possible by setting php headers? And most developers, given same platform [php/apache/ssl] would store the posted data in a session if they wanted to re-populate the fields?

Thanks,
Jon

mattjp88

right, the only way I can think of to ensure that the data is repopulated is if you link back to the page, and discourage the user from using the back button. if they do that, you can't do anything to repopulate, because the page is loaded from cache, not from your server, so your scripts are useless. so I would say, set all submitted data to session variables, and then on the page being submitted to, have a link back to the other page, and encourage the user to use that link instead of the back button.

-Matt

jongenant

ASKER

I figured out my problem. I was running apache mod_rewrite and serving the form from a dispatch page which had an unnecessary call to session_start before it loaded the form (i.e. dispatch.php code: <? session_start(); .... include(form.php); ?>; form.php code:<? headers from original post; session_start(); ... ?>). For the above php headers/session_cache_limiter to work, they need to be called before session_start(). Figured this out by testing the form on another ssl enabled domain that wasn't using mod_rewrite. (mod_rewrite by itself was not the problem, the fact that session_start() was called in dispatch page before the headers/session_cache_limiter on the form page was).

Viewer's form data is now present/retained in the form fields when clicking back button after form submission. So yes, looks like I can have a private, client side cache over SSL with the php headers. This is the same effect of using 'header("Cache-control: private");' under non-SSL conditions.

...the idea was just to offer some basic viewer assurance of site functionality, but was never 100% necessary, i.e:
viewer submits form successfully, reaches the thank you page, then, with nothing more to do, clicks back to wherever they came from and during the process, he/she traverses back over the form pages which, instead of being blank [i.e. the problem], contain their original data. No need to 're-populate' the fields programatically (via session, javascript, or other means), they just 'retain' the orignal data now b/c of private, cache-control headers and session_cache_limiter.

Appreciate your responses.
Jon

ASKER CERTIFIED SOLUTION

CetusMOD

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial