Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 4 of 4
  1. #1
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Question $_POST vs $HTTP_POST_VARS - which one is recommended? I forget...

    Hmmm, seems like only yesterday that the PHP site was harping on about how we should use $HTTP_POST_VARS and friends instead of the equivalent $_POST - at least, I think they were, or maybe I got confused.

    Now it seems that $_POST style is recommended over $HTTP_POST_VARS style, in part because the $_POST style ones are apparently superglobals...? Hmmm...

    Any thought on this, anyone? Which are you "supposed" to use (both are supported) plus the advantages etc.

    I have found in some cases I have had to declare $_POST inside a function, which I should not have to do, and of course that tends to muck things up a bit, which is why perhaps I should stick to the other way...?

    ::] krycek [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #2
    New Coder
    Join Date
    Jun 2002
    Location
    hamilton,ontario
    Posts
    46
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Use $_POST because like you said it's superglobal. In new versions of php register globals are turned off be default.

    Here is what php.net has to say about them both


    Note: Introduced in 4.1.0. In earlier versions, use $HTTP_POST_VARS.

    An associative array of variables passed to the current script via the HTTP POST method. Automatically global in any scope.

    This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_POST; to access it within functions or methods, as you do with $HTTP_POST_VARS.

    $HTTP_POST_VARS contains the same initial information, but is not an autoglobal. (Note that HTTP_POST_VARS and $_POST are different variables and that PHP handles them as such)

    If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the $_POST and $HTTP_POST_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals
    whittys.com
    Nomsane?
    That is all

  • #3
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts
    kinda like I thought, then cheers!

    ::] krycek [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #4
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,073
    Thanks
    11
    Thanked 98 Times in 96 Posts
    pre $_POST users were encouraged to use $HTP_POST_VARS as a secure alternative to $post_variable.

    "I have found in some cases I have had to declare $_POST inside a function"

    then you have issues elsewhere , $_POST is always global in scope ... note that

    $_POST['variable']
    and
    $_POST[variable]

    are in fact 2 different variables which does sometimes cause confusion , especially when $_POST[variable] will take on the value of $_POST['variable'] (if exists) if 'variable' is not defined.
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •