HTTP_Post_Vars

Anon

Greetings,

A little confused by this HTTP_POST_VARS thisg. IF you have multiple users will the vars entered by another user be in the assoc. array or is it more of a session type of deal where the array is unique to the user? If so how is it identifying the user?

thanks

Jim

Anon

it is specific for each individual request, so $HTTP_POST_VARS will not contain info some other user entered. There is no need to worry about other requests (as far as variables go) when programming a php page...just worry about what one individual request will require.

Anon

Tom,
Thanks for your reply! So it is similar to the way a session variable is stored? How is it working (ie a session sets a cookie to id the session and vars in question) how does it know?

thanks

peter

Anon

Not at all. Some page on your site (or even somebody else's)
sends html to the client's browser that contains a <form>.
The form contains one or more <input>, <select>, or
<textarea> tags. When the user clicks on the SUBMIT
button, the data in the input tags is sent back to your server,
and the page that is being thus POSTed to received the variables
as a sequence of name=value pairs separated by ampersands.
PHP automatically parses these and places them into the
HTTP_POST_VARS associative array, and if 'track_vars' is on
it also creates individual variables for each of them.

In other words, coming from an individual web-page form from
an individual user's browser, which invokes a separate instance
of the receiving web page that is totally separate from any other
process/thread on your web server.

Anon

Kirk,

Thanks, Im kinda starting to understand, but if that is the way it works how long are the vars in the HTTP_POST_VARS available for? the lenght of the user visit or for one page following the form submit?

thanks again

jim

Anon

HTTP_POST_VARS has no connection with sessions. Everything
disappears at the end of the script. Nothing prevents you from
registering any or all of them as session variables if you want to,
of course.

Anon

Kirk,

I know that it has NOTHING to do with sessions, but the functionality seems similar for persistance of data.  UNLESS im not getting it.  So how long are the values for vars in HTTP_POST_VARS available?

thanks

Jim

Anon

They are NOT persistent. Sorry if I failed to make that clear:
the POST variables disappear when your session exits the same
as any other variable.

Anon

Kirk,

Thank you for responding! I noticed you called the Post a session (i am assuming a typo) but how long are the HTTP_POST_VAR available to the user?  Is is just for one page like anyother variable?  (I think this is where we are going.)

IF this is the case how can you make persisatnt vars without the use of sessions and cookies? Can it be done? In order for and instance variable to be persistant it needs to be ID'd by a session(Do i have this right?)

thanks again

Anon

I give up... I've searched for over an hour for a topic I know I've read on here before. Bottom line... I'm looking for the piece of code to read form variables and then only print those that are not empty.

Anon

Perhaps you don't have a clear concept of how HTTP works?
The client browser makes a tcp/ip connection to the web
server and sends one of three possible request types:

(1) GET, which simply requests a web page, image, or
other file (including php pages). The request may
contain additional header lines that send back cookie
information, control caching, describe the browser in
use, etc. The request is ended by a blank line.

At this point, the browser is all done sending data to
the server. The server then responds by sending back
a response packet, containing one or more header lines
(such as OK or a numeric error message such as 404 for
page not found.) The header is followed by the data
requested (if any), typically html-formatted text in the
case of an ordinary web page. At this point, the http
transaction is <b>over</b>. The client and server may
conspire to keep the tcp/ip session alive as a way to
increase performance, but this is completely hidden from
the higher levels of the server and browser and any
subsequent page requests proceed exactly as if the
tcp/ip session were terminated and needed to be established
all over again.

(2) POST, which works exactly as does GET, except that the
clients request header is followed by any variables from the
form as name=value pairs.

(3) PUT which is not much used and will not concern us here.

Cookies were first proposed by Netscape as a way to store
a limited amount of information at the browser between http
requests, and so allow a browser to maintain state as it moves
between the various pages of a web site. If your data needs
are minimal, you can just store the data as a cookie (and hope
your users haven't disabled cookies) but more often you will
just store an identifier that is used to identify data that you
have saved on the server as part of a previous http transaction.
(This is essentially what "php sessions" do, whether you use
PHPLIB, the session support build into 4.x, or roll your own.)
It is also possible to pass the session identifier as part of the
URL.

To summarize, http is inherently stateless, and the information
associated with the requesting and displaying of a single page
is inherently transitory, unless you take special steps to save
the data at the server between pages, and provide the client
with some method of telling the server which set of saved data
to restore.

Anon

Well ... if they're empty, nothing prints. :-)

But perhaps you want to do this:

if ($myformvariable)
{
echo "Buncha stuff";
dosomethingelse();
echo $myformvariable;
}
else
complain("You forgot to fill out the form!");

Anon

Dear Kirk,
Thanks a lot for that last explanation! I didn't understand the difference between GET and POST and it was causing me problems. It was sort of unrelated to the topic on this thread but I happened across your explanation and fixed my problem!
Jeremy