NYCPHP Meetup

[George Webb]

>  George,
>  If I "include"/"require" this file, can I still access $HTTP_POST_VARS[] 
>  values without a session.
>  (I have to use $HTTP_POST_VARS[], because _POST[] isn't supported on the 
>  server I'm on).
> 
>  I just want to access a $HTTP_POST_VARS[] variable on the second page 
>  for use in a hidden form.

	Sure; all global variables are still available to include()'d 
and/or require()'d scripts.  $HTTP_XXX_VARS, however, does require the
"global" declaration if you use it inside the scope of a function.
In more recent versions, the $_POST, $_GET, etc. arrays are "superglobals"
which means you don't have to use the "global" declaration with them;
they're available everywhere.  Plus, $_POST is much easier to type.

>  >       Also, I don't know how much data is getting POSTed, but if
>  >it's more than a few hundred characters (or has the potential to be),
>  >you might have problems doing Location: redirects with all that data.
>  >I could explain this further if it doesn't make sense.
>  >  
>  >
>  Could you explain this?  I thought you couldn't pass any data using 
>  header("Location: ").
>  I'm still inexperienced with PHP, so I need an explanation.

	This is actually the difference between the GET and POST method
for HTTP.  You know how your HTML form can have an METHOD of either "GET"
or "POST".  If it's GET, your browser simply (?) throws all the fields
together and puts them on the end of your ACTION URL.  Example:

<FORM METHOD=GET ACTION="http://yourserver.com/form-handler.php">
Name: <INPUT NAME="myname" SIZE=20> <BR>
Question: <TEXTAREA NAME="myquestion" COLS=30 ROWS=8></TEXTAREA> <BR>
<INPUT TYPE=SUBMIT VALUE="Submit Question">
</FORM>

	If the user types in their name ("George") and their question
("Help!!!"), then the browser would use the regular old HTTP GET method
to get the following URL:

http://yourserver.com/form-handler.php?myname=George&myquestion=Help%21%21%21

	As you can see the form data is simply (?) appended to the
, after a question-mark, and separated by ampersands.  Each element, also,
is url-encoded, e.g. exclamation points become %21.

	You could also type this same string into a web browser to
see the exact same effect.

	On the other hand, if you change that example to use METHOD=POST,
then the browser issues a POST request instead of a GET request to the
server, and the requested URL would be simply 
http://yourserver.com/form-handler.php.  Nothing appended to the URL.  Then
the form data is assembled in the same simple (?) way in the body of the
HTTP request, which users typically never see.

	So, to answer your question, the reason you should use POST requests
with a large amount of data is because if you used GET, the URL would become
too long for the server.  In this example, if the user typed a really long
question (or pasted a really long string like a RFC document), the server
would probably barf after reading about 1000 characters from the URL.  If
you use POST, there is not such a limitation to the length of the submitted
form data.

	There are other reasons also why you might not want to use GET method
requests for forms.  One is server logs typically store the entire request
URL, so in a shared ownership environment where everyone can view each other's
server logs, everyone can see all the other users' submitted data.  Privacy
issue.

	Another issue is caching pages when browsers navigate backwards --
browsers are more likely to silently re-submit a form request with a GET method
than with a POST request.  So if you had a Form Mail script, for example, if
your users went back to the form page and then forward again, the data *might* be
submitted again (depending on some configuration settings).  With POST method,
browsers tend to confirm that the user really wants to re-POST, before it
just goes and sends all that data again.  In Netscape, the alert is something
like "Repost Form Data? [Cancel] [OK]".

	Another issue with redirects from a form-submit (GET or POST) is that
the posted data is not actually available to the redirected script.  So if you
post to /scriptA.php which does nothing except redirect to /scriptB.php, 
scriptB.php will not actually see the submitted data, unless scriptA.php sticks
it on the end of the redirected URL, like the browsers do.  Either way, the
redirected script will have to use the GET method, even if the browser request
was a POST method.

	Hope that's not too verbose; I just had a Code Red.


Most Bestly,

George Webb
gw.nyphp at gwprogramming.com