Also far too many people use $_REQUEST when they really only want to use a $_POST and open their site up to a whole slew of potential cross site scripting exploits.
IMHO $_REQUEST should only be used in exceptional circumstances.
- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Reply to: Easy Peasy PHP Question
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on "Easy Peasy PHP Question"
Collapse
-
It annoys me too - just a few months ago I ranted to a colleague for five minutes non-stop after wasting loads of time tracking down an error-that-wasn't-an-error-to-PHP, much to his amusementOriginally posted by bogeyman View PostOk, it's a notify rather than an error but that's one of the things that annoys me about PHP - too much inconsistency and 'special' cases. If it were a regular array rather than a '$_' one then you'd get an error - and rightly so.
You're probably right about expecting a specific HTTP method but I have found odd situations where I've needed to cater for both in the same code - although it's probably not best practice to do so. So I've changed my mind re $_REQUEST - it probably just invites security problems.
It's reasonable enough to have a script that expects both a GET and a POST - the typical case is a form where, on GET, you show the form and, on POST, you validate the input, re-display the form with error messages in the case of problems, and otherwise redirect to the appropriate destination. But a script that should only be accessed by a subset of methods (say GET and HEAD) is safest checking.
Leave a comment:
-
Ok, it's a notify rather than an error but that's one of the things that annoys me about PHP - too much inconsistency and 'special' cases. If it were a regular array rather than a '$_' one then you'd get an error - and rightly so.Originally posted by NickFitz View PostNope. Using the default configuration, attempting to access an undefined index in $_GET will return NULL, as shown if you run the following:
For example.com/blah.php, this echoes "thingy is NULL". for example.com/blah.php?thingy=Fred it echoes "thingy is Fred".Code:$value_of_thingy = $_GET['thingy']; echo('thingy is '.(is_null($value_of_thingy) ? 'NULL' : $value_of_thingy));
You can change the error reporting level so as to show an error in this case (E_NOTICE is the one, I believe, defined as "the script encountered something that could indicate an error, but could also happen in the normal course of running a script") but the default for PHP 4 and PHP 5 is not to notify such an error. It's recommended that the stricter level of error reporting only be used for development, never on a deployed application.
Having said that, it is usually sensible to adopt your approach of using isset() to determine whether the parameter has been passed and react accordingly. Alternatively the script should behave gracefully in the event of having a parameter whose value is NULL.
Personally I'm not much in favour of using $_REQUEST. I tend to be very strict about HTTP methods, so if I have a script that only expects an HTTP GET and somebody tries to do an HTTP POST to it, I'm not going to act as if that's OK: they're probably probing for weaknesses, so they can have a 405 Method Not Allowed for their trouble
You're probably right about expecting a specific HTTP method but I have found odd situations where I've needed to cater for both in the same code - although it's probably not best practice to do so. So I've changed my mind re $_REQUEST - it probably just invites security problems.
Leave a comment:
-
Nope. Using the default configuration, attempting to access an undefined index in $_GET will return NULL, as shown if you run the following:Originally posted by bogeyman View PostWhat if 'thingy' isn't provided in the HTTP GET request?
You'd get an invalid index error.
$value_of_thingy = (isset($_GET['thingy']) ? $_GET['thingy'] : false);
Also may be better to use $_REQUEST[] rather than $_GET[].
</pedant>
For example.com/blah.php, this echoes "thingy is NULL". for example.com/blah.php?thingy=Fred it echoes "thingy is Fred".Code:$value_of_thingy = $_GET['thingy']; echo('thingy is '.(is_null($value_of_thingy) ? 'NULL' : $value_of_thingy));
You can change the error reporting level so as to show an error in this case (E_NOTICE is the one, I believe, defined as "the script encountered something that could indicate an error, but could also happen in the normal course of running a script") but the default for PHP 4 and PHP 5 is not to notify such an error. It's recommended that the stricter level of error reporting only be used for development, never on a deployed application.
Having said that, it is usually sensible to adopt your approach of using isset() to determine whether the parameter has been passed and react accordingly. Alternatively the script should behave gracefully in the event of having a parameter whose value is NULL.
Personally I'm not much in favour of using $_REQUEST. I tend to be very strict about HTTP methods, so if I have a script that only expects an HTTP GET and somebody tries to do an HTTP POST to it, I'm not going to act as if that's OK: they're probably probing for weaknesses, so they can have a 405 Method Not Allowed for their trouble
Leave a comment:
-
What if 'thingy' isn't provided in the HTTP GET request?Originally posted by NickFitz View PostCode:$value_of_thingy = $_GET['thingy'];
You'd get an invalid index error.
$value_of_thingy = (isset($_GET['thingy']) ? $_GET['thingy'] : false);
Also may be better to use $_REQUEST[] rather than $_GET[].
</pedant>
Leave a comment:
-
-
Originally posted by Platypus View PostNick, many thanks! Just what I needed.
DP, it's a fair cop, I admit I was being VERY lazy

For future reference...
Leave a comment:
-
Nick, many thanks! Just what I needed.
DP, it's a fair cop, I admit I was being VERY lazy
Leave a comment:
-
Blimey, that's a pretty basic bit of missing knowledge. Why not get a good book on the subject for beginners (tutorial style)?Originally posted by Platypus View PostFolks,
If I type the following into my browser (or hyperlink to it):
Then when I'm writing the PHP code in mypage.phpCode:www.mysite.com/mypage.php?thingy=platypus
How can I access the "thingy" variable and get its value?
Thanks!
Leave a comment:
-
Originally posted by Platypus View PostFolks,
If I type the following into my browser (or hyperlink to it):
Then when I'm writing the PHP code in mypage.phpCode:www.mysite.com/mypage.php?thingy=platypus
How can I access the "thingy" variable and get its value?
Thanks!Code:$value_of_thingy = $_GET['thingy'];
Leave a comment:
-
Easy Peasy PHP Question
Folks,
If I type the following into my browser (or hyperlink to it):
Then when I'm writing the PHP code in mypage.phpCode:www.mysite.com/mypage.php?thingy=platypus
How can I access the "thingy" variable and get its value?
Thanks!Tags: None
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers

Leave a comment: