NYCPHP Meetup

[David Krings]

Brian D. wrote:
> I can't find where I read it originally, but somewhere I've been told
> or read that "using $_REQUEST is bad form." I understand that in cases
> where you want to force a $_POST request, but if you might receive
> $_GET or $_POST then isn't is better than doing if/elses?

I recall that this was discussed several weeks ago on this mailing list, so 
you may want to look through the archives.
I never came across the situation where I didn't know if the incoming data 
comes fro a GET or a POST. In any case, I do want to know as I'd trust a GET 
even less than a POST to deliver some sane and safe data (not that I wouldn't 
check / prepare it anyway).
IIRC the matter is not using or not using REQUEST, but what one does with the 
stuff that is returned.


> The only related thing I could find on Google was this guy (
> http://mypetprogrammer.com/blog/?p=15 ) but he seems to erroneously
> believe that using $_POST somehow saves you from a SQL injection
> attack.
You're saying it doesn't? But it still saves one from parse errors and 404s....


> I'm also thinking that some servers don't use the $_REQUEST array.
That is possible. Server provided arrays are something that really baffles me, 
especially the wild variations between the various $_SERVER implementations.


> Can you define why it's bad form? When is it considered acceptable to use?

As mentioned above, I don't think it is "bad", but more dangerous in the sense 
that you may not get anything when the server does not craft this array. It is 
more that you need to know what to do with the data. I do wonder if there ever 
is a situation where it is unknown if date comes from POST or GET. Since you 
know what the variables are called and are supposed to contain, isn't it 
reasonable to assume that  one also knows how the data gets submitted?

David