Link to home
Start Free TrialLog in
Avatar of dplambert
dplambert

asked on

Can SSI's see POSTed values

If I POST a form to a HTML page that has the following server side include in it:

<!--#exec cgi="cgi_bin/include/process.pl"-->

Will process.pl be able to work with the POSTed form values?
Avatar of lexxwern
lexxwern
Flag of Netherlands image

no. but you can send the values to the SSI thru query strings like this,
<!--#exec cgi="cgi_bin/include/process.pl?$VALUE"-->

in process.pl this can be fetched thru the following variable

$ENV{'QUERY_STRING'};
Avatar of dplambert
dplambert

ASKER

What if the form uses the GET method? I know that SSI's can see certain environmental variables of the caller, so I would think that QUERY_STRING would be populated.
stop ! rethink what is happening:

  1. server parses html file, substitutes SSI statements
  2. server delivers result to client
  3. client (user) pushes button

when 3. happens, there is no longer any SSI available, so only what lexxwern suggest can work
I'm terribly sorry, but I ran some tests and I can see POST and GET form values in a CGI #EXEC include. Perhaps this isn't the case on all servers, but the web hosting company that I'm working with company (threadnet.com) can do it.
where (physically) do you see the CGI #exec, and where the POST?
I had a form POST to a HTML page that contained a CGI #EXEC include. The include Perl file could see the POSTed data.
again, **where** do you see #exec: on server or in browser?
If your CGI sees the POSTed data, where is the problem then?
The server sees it, not the browser.
im not able to follow this here. lets look at things again...


(1) a form is posted to a certain cgi script.
(2) the cgi script has an SSI include and some HTML.
(3) you asked if SSI could see the posted variables sent to the main script, we said no.
(4) but when you included the other script through "exec cgi" and not "include file" you say it could see the variables, which i think it shouldn't but it apperently does on your system.
(5) but then you say,
>> The server sees it, not the browser.
i interpret this as you tried to print this posted variable thru your included file, but it gave out a null.

which means that the included script cannot access the posted variables from the main script.

is this what is happening. please correctme if my interpretation is wrong.
and what has any FORM to do with the cgi processed on the server **before** the page (containing the GET FORM) is delivered to the browser?

Could you please explain what's the problem with lexxwern's suggestion?
testform.html has a <FORM> element with an ACTION attribute of "testform.html" (itself). It also has the following code in it:

<!--#exec cgi="cgi_bin/include/process.pl"-->

This directive is executed server-side, so only process.pl's results get sent to the browser.

There is no Perl in testform.html - it only has HTML. The Perl code is in process.pl.

The Perl code can see the POSTed form values, which I find very interesting.
dplambert, please reread my very first comment until you're *used to the data flow* with SSI and FORMs
IMHO you're not understanding what happens, at the moment.
To get more used to it, also use the browser's "View Source" (or whatever it is called there), and compare that to your page you see on the server.
ASKER CERTIFIED SOLUTION
Avatar of lexxwern
lexxwern
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ahoffmann -

<!--#exec cgi="cgi_bin/include/process.pl"--> never makes it to the browser per view source. It's substituted with the results (prints) of process.pl.

I agree that it's not the best way to do things.

Bottomline, I don't have a problem now. I posed a question and got the answer myself while testing. I didn't explain the question well enough.
> I agree that it's not the best way to do things.
don't agree: SSI is a good, and a portable way to do things ;-)

IMHO lexxwern answerd your question.