I agree users should definitely know where their data comes from. Obviously reliance simply on POST is silly. That's where Zend_Validate/Filter type functions come into play.
I think Chris is getting at the fact GET shouldn't be used for actions that change data (i.e. delete, add records, etc). Though many apps do this, it is against the HTTP spec and can lead to unpredictable results (i.e. when Google Accelerator followed all links in a document and started actioning delete links). I've been guilty of this myself in the past. I originally made this comment since it seemed that functions within ZF were returning POST variables not purely from POST, but from a mulch of POST/GET/URL. If the function exists, chances are users will use them. And that seems to promote bad practise. I'm in favour of users sticking to good old $_POST and $_GET so they know exactly where things come from and can plan their security appropriately. The old Zend_Filter_Input used to give users access to $_POST and unset _POST so they were encouraged to filter all incoming data. That seemed useful, though I understand progress has made that undesirable now. If any ZF functions do return POST to the user for their own scripts, they should have a good reason for doing so (and ideally add functionality / or encourage security practises) otherwise it seems simpler to just stick with existing superglobals that people understand. Security is a big thing, more so perhaps in the PHP world where there has been bad press in the past. Seems like a good topic for a tutorial, or even an additional manual section, for ZF 1.0 ... best wishes, Si
