The most direct answer to my original question was from Brent: "It's bad form because you should know whether data is being passed to you from a form or via the url."
While this is partially correct, I believe that you could run into situations that you want to accept both (e.g., a record ID via a hidden field or via a GET). I'm aware of the differences between POST and GET, I just wasn't sure why using the $_REQUEST array was considered bad form. Another good point that was made: "Mainly, the issue comes into play when you don't get to design/dictate the entire site OR you count on external web developers to call your app for some reason." As far as I can tell there's nothing fundamentally wrong with using $_REQUEST, but if you can control how the data is passed, more power to you. One last question, David, you said in reference to $_POST saving one from SQL injections: "You're saying it doesn't? But it still saves one from parse errors and 404s...." Using $_POST over $_REQUEST makes no difference in what you receive - you'll still have to escape data that you put into a SQL query either way. How does using $_POST save one from parse errors and 404s? Thanks for all of the feedback. _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
