Topic awaiting preservation: $HTTP_GET_VARS

hi

I'm doing my company site right now. so i don't want to
use frames (framesets even iframes) so i decided to
use php and include i.e require

I get my content with this simple code:

<?php

        IF(!isset($HTTP_GET_VARS['slide']))

        {

           include ('start.php');        

        }

        ELSE

        {

           require ($slide.".php"); 

        }

?>

whats my problem is that the local installed
apache/php server don't show me the included
part of the page.
but if the page is uploaded to my hoster all works
fine.
I'm sure theres a problem with the '$HTTP_GET_VARS'
in a local area.

how can i test the site without always change the code?

Xdreamer.ch: It might depend on your local version of PHP as they have changed the name of the global GET variable - try $_GET but have a look at the manual on the variables page.

___________________
Emps

FAQs: Emperor

ok thanks emperor. i'll have a look at it :mosh:

Well...let's see...the variable $HTTP_GET_VARS can be simplified down to the variable $GET and I think it should be $GET["slide"] instead of $GET['slide'] (but that may not matter at all.

It would probably help as well if you actually defined the variable $slide before you tried to use it. before the if() statement just try putting:

$slide = $GET["slide"];

and noticing that you said that it works fine when uploaded...it could be a difference in settings between your PHP install and your server's, like there is one setting (I think) that toggles the use of the $HTTP autoglobals...

thank you very much. give it a try later...have to go now

so can't resist. seems that it be $_GET how emperor
said, thanks both of you. works fine now




[This message has been edited by Xdreamer.ch (edited 04-14-2003).]

there is no actual difference in $GET['slide'] and $GET["slide"]...

Didn't think so...just wanted to be sure.

For anyone who might be interested in WHY this little problem occurred, I'm going to stick out my neck, and possibly start a discussion on it ...

I'm a bit rusty, so I might have gotten some of my nomenclature wrong. I recommend a visit to the PHP web site to verify - Check the page on pre-defined variables

If you're calling the php scripts through a web server (i.e. not from the command line) there should be no difference in operation. However ... it is very likely that your ISP is making allowances for older scripts and will have set the register_globals directive (in php.ini) to true, to make sure of reverse compatibility. Most ISPs do this right now ... On the other hand, a brand new installation of a post-4.2.0 installation will have register_globals set to FALSE by default. It sounds as though that's how yours is set up at home.

Under the new regime inside PHP, $HTTP_GET_VARS and it's pals are not super_globals, so they need to be declared as global before they are used. However $_GET and its friends ARE super_globals, so they're always avaiable. This would explain why $HTTP_GET_VARS isn't working on your box and is on theirs. For verification, try using the parameter name itself as the variable name e.g. refer to $testvar after calling the script with URL/FILE?testvar=HelloWorld ... it will probalbly still work at the ISP end, but not at yours.

Personally I like using $_REQUEST because it contains all the elements of $_GET, $_POST, and $_COOKIE in one array.

quote:

---

(from the PHP web site) register_globals - boolean
Tells whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables. For example; if register_globals = on, the url http://www.example.com/test.php?id=3 will produce $id. Or, $DOCUMENT_ROOT from $_SERVER['DOCUMENT_ROOT']. You may want to turn this off if you don't want to clutter your scripts' global scope with user data. As of PHP 4.2.0, this directive defaults to off. It's preferred to go through PHP Predefined Variables instead, such as the superglobals: $_ENV, $_GET, $_POST, $_COOKIE, and $_SERVER. Please read the security chapter on Using register_globals for related information.

---

Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

[This message has been edited by trib (edited 04-26-2003).]

It is all about extra security measures. Helping to make sure you validate all your variables and such.

I remember when I started coding it would have been as simple as:

<?

if(!$slide){include("start.php");}

else{ include($slide);}

?>

Oh how times change. It is probabally for the better, as newer users are less likely to make the blunder I made about by allowing a variable to access internal functions unchecked.

Imagine this query: yoururl.com/page.php?slide=c:\windows\php.ini
or : yoururl.com/page.php?slide=/etc/passwd (since your host is probabally a unix host.
Even less suttle: yoururl.com/page.php?slide=./.passwd or ./.htaccess

I mean you could be really fucked there. Make sure to validate the input.


Me