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/proce ss.pl"-->
Will process.pl be able to work with the POSTed form values?
<!--#exec cgi="cgi_bin/include/proce
Will process.pl be able to work with the POSTed form values?
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
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
ASKER
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?
ASKER
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?
If your CGI sees the POSTed data, where is the problem then?
ASKER
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.
(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?
Could you please explain what's the problem with lexxwern's suggestion?
ASKER
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/proce ss.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.
<!--#exec cgi="cgi_bin/include/proce
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.
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ahoffmann -
<!--#exec cgi="cgi_bin/include/proce ss.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.
<!--#exec cgi="cgi_bin/include/proce
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.
don't agree: SSI is a good, and a portable way to do things ;-)
IMHO lexxwern answerd your question.
<!--#exec cgi="cgi_bin/include/proce
in process.pl this can be fetched thru the following variable
$ENV{'QUERY_STRING'};