Dynamic, dynamic pages.

Ahh yes lets make it more complicated.

[BoneHeadicus]

OK. Lets say I am using an ssi to call a cgi that presents a page to the user based on certain criteria. I have the AddHandler statement in .htaccess to execute the ssi using .htm or .html.

However I want the user pages to be dynamically produced by PHP. I already sorta understand the fact that the page won't be parsed due to the fact that it has already been parsed. Not to be hindered lets do a 0 refresh on the presented user page that leads to the .php page. But wait that should have been an .html page!
So do I:

use mod_rewrite to make .php .html or is there some other way?

will I lose the referring url in the refresh?

The whole point is to cloak and produce a page that dynamically writes the referring keywords into a .swf to present to the user.

[Air]

There isn't a real easy way to keep the same extension while using SSI to call a cgi (Perl, I assume?) and have php execute for some of the visitors and use the same extension as the included cgi for php. Wow that's a mouth full.

Using the same redirect technique but with a few changes, a variation of what you describe will work. It goes like this -

Use only one AddHandler statement and remove the other from your .htaccess file. Suppose the AddHandler for .htm is the one you choose to remove, then add AddType application/x-httpd-php .htm to your .htaccess file.

Now you can use thispagename.html for the .cgi files and redirect the chosen visitors to thispagename.htm for the php files.

Only a few sharp eyed folks will ever notice that the extension changed from .html to .htm

I can't think of any other way to make this work and keep the same extension for both, even with mod_rewrite.

A variation of this is to add an uppercase i to the extension so that .htm looks like this: htmI the fonts used in the browser addrss window make this look like html, the number 1 could also accomplish the same thing. Of cousrse if people type in the URL and use what they believe to be .htmL then you could open yourself up to 404's.

[added]oh, wait, now that I think about it, even if the user types in the url with the .html extension the variation above will still work. The user unwittingly calls the cgi and is identified by the cgi as someone that should the receive the php page, and is redirected to thispagename.htmI (the php page)[/added]

[BoneHeadicus]

Outstanding post Air. You really have an eye for detail.

It occurred to me that perhaps I'm thinking wrong. The cgi script might already be stripping the keys out of the url. Is there a way to pass this as a variable on to the php script?

[Air]

Well, now we're talking about how to maintain state, since http is a stateless protocol the session variables don't live from one page to the next. There are ways to handle it within php by using sessions, or with CGI.pm in perl but when crossing perl/cgi with php then you will probably need to set a cookie with the perl/cgi and retrieve it with the php in order for the information to live from one page to the next.

Check this out [wdvl.com] for more information on these techniques,
and This One [cookiecentral.com] for cookie specific info.

[BoneHeadicus]

Would it be possible to write on the "presented" user page or would a cookie have to carry the session over after a redirect?

[Air]

You could do it either way, if you have previously "written" the info to a file you can read it from the php page and present it to the user. The cookie can serve the same purpose except that you write to the users' disk and you don't have to keep track of what-you-wrote-to-what-file for which user.