Javascript debugger
Website design
↑
Since PHP 4.1.0, the preferred method for retrieving
external variables is
with the superglobals mentioned below. Before this time, people relied
on either register_globals
or the long predefined PHP arrays ($HTTP_*_VARS
).
As of PHP 5.0.0, the long PHP
predefined variable
arrays may be disabled with the
register_long_arrays
directive.
Introduced in 4.1.0. In earlier versions, use
$HTTP_SERVER_VARS
.
$_SERVER
is an array containing information
such as headers, paths, and script locations. The entries in this
array are created by the web server. There is no guarantee that
every web server will provide any of these; servers may omit some,
or provide others not listed here. That said, a large number of
these variables are accounted for in the » CGI 1.1 specification, so you should
be able to expect those.
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
$_SERVER; to access it within functions or methods, as
you do with $HTTP_SERVER_VARS
.
$HTTP_SERVER_VARS
contains the same initial
information, but is not a superglobal. (Note that
$HTTP_SERVER_VARS
and $_SERVER
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
$_SERVER
and $HTTP_SERVER_VARS
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
You may or may not find any of the following elements in $_SERVER. Note that few, if any, of these will be available (or indeed have any meaning) if running PHP on the command line.
PHP_SELF
'
The filename of the currently executing script, relative to
the document root. For instance,
$_SERVER['PHP_SELF']
in a script at the
address http://example.com/test.php/foo.bar
would be /test.php/foo.bar
.
The __FILE__
constant contains the full path and filename of the current (i.e.
included) file.
If PHP is running as a command-line processor this variable contains the script name since PHP 4.3.0. Previously it was not available.
argv
'argc
'GATEWAY_INTERFACE
'CGI/1.1
'.
SERVER_ADDR
'SERVER_NAME
'SERVER_SOFTWARE
'SERVER_PROTOCOL
'HTTP/1.0
';
REQUEST_METHOD
'
Which request method was used to access the page; i.e. 'GET
',
'HEAD
', 'POST
', 'PUT
'.
PHP script is terminated after sending headers (it means after
producing any output without output buffering) if the request method
was HEAD
.
REQUEST_TIME
'QUERY_STRING
'DOCUMENT_ROOT
'HTTP_ACCEPT
'Accept:
header from the
current request, if there is one.
HTTP_ACCEPT_CHARSET
'Accept-Charset:
header
from the current request, if there is one. Example:
'iso-8859-1,*,utf-8
'.
HTTP_ACCEPT_ENCODING
'Accept-Encoding:
header
from the current request, if there is one. Example: 'gzip
'.
HTTP_ACCEPT_LANGUAGE
'Accept-Language:
header
from the current request, if there is one. Example: 'en
'.
HTTP_CONNECTION
'Connection:
header from
the current request, if there is one. Example: 'Keep-Alive
'.
HTTP_HOST
'Host:
header from the
current request, if there is one.
HTTP_REFERER
'HTTP_REFERER
as a feature. In
short, it cannot really be trusted.
HTTP_USER_AGENT
'User-Agent:
header from
the current request, if there is one. This is a string
denoting the user agent being which is accessing the page. A
typical example is: Mozilla/4.5 [en] (X11; U;
Linux 2.2.9 i586)
. Among other things, you
can use this value with get_browser() to
tailor your page's output to the capabilities of the user
agent.
HTTPS
'Set to a non-empty value if the script was queried through the HTTPS protocol.
Note that when using ISAPI with IIS, the value will be
off
if the request was not made through the HTTPS
protocol.
REMOTE_ADDR
'REMOTE_HOST
'
The Host name from which the user is viewing the current
page. The reverse dns lookup is based off the
REMOTE_ADDR
of the user.
Your web server must be configured to create this variable. For
example in Apache you'll need HostnameLookups On
inside httpd.conf
for it to exist. See also
gethostbyaddr().
REMOTE_PORT
'SCRIPT_FILENAME
'The absolute pathname of the currently executing script.
If a script is executed with the CLI, as a relative path,
such as file.php
or
../file.php
,
$_SERVER['SCRIPT_FILENAME']
will
contain the relative path specified by the user.
SERVER_ADMIN
'SERVER_PORT
'80
';
using SSL, for instance, will change this to whatever your
defined secure HTTP port is.
SERVER_SIGNATURE
'PATH_TRANSLATED
'Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping.
As of PHP 4.3.2, PATH_TRANSLATED
is no longer set
implicitly under the Apache 2 SAPI in contrast
to the situation in Apache 1, where it's set to the same value as
the SCRIPT_FILENAME
server variable when it's not
populated by Apache. This change was made to comply with the
CGI specification that
PATH_TRANSLATED
should only exist if
PATH_INFO
is defined.
Apache 2 users may use AcceptPathInfo = On
inside
httpd.conf
to define PATH_INFO
.
SCRIPT_NAME
'REQUEST_URI
'/index.html
'.
PHP_AUTH_DIGEST
'PHP_AUTH_USER
'PHP_AUTH_PW
'AUTH_TYPE
'
Introduced in 4.1.0. In earlier versions, use
$HTTP_ENV_VARS
.
These variables are imported into PHP's global namespace from the environment under which the PHP parser is running. Many are provided by the shell under which PHP is running and different systems are likely running different kinds of shells, a definitive list is impossible. Please see your shell's documentation for a list of defined environment variables.
Other environment variables include the CGI variables, placed there regardless of whether PHP is running as a server module or CGI processor.
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
$_ENV; to access it within functions or methods, as
you do with $HTTP_ENV_VARS
.
$HTTP_ENV_VARS
contains the same initial
information, but is not a superglobal. (Note that
$HTTP_ENV_VARS
and $_ENV
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
$_ENV
and $HTTP_ENV_VARS
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
Introduced in 4.1.0. In earlier versions, use
$HTTP_COOKIE_VARS
.
An associative array of variables passed to the current script via HTTP cookies. 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
$_COOKIE; to access it within functions or methods, as
you do with $HTTP_COOKIE_VARS
.
$HTTP_COOKIE_VARS
contains the same initial
information, but is not a superglobal. (Note that
$HTTP_COOKIE_VARS
and $_COOKIE
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
$_COOKIE
and $HTTP_COOKIE_VARS
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
Introduced in 4.1.0. In earlier versions, use
$HTTP_GET_VARS
.
An associative array of variables passed to the current script via the HTTP GET 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
$_GET; to access it within functions or methods, as
you do with $HTTP_GET_VARS
.
$HTTP_GET_VARS
contains the same initial
information, but is not a superglobal. (Note that
$HTTP_GET_VARS
and $_GET
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
$_GET
and $HTTP_GET_VARS
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
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 a superglobal. (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 superglobals.
Introduced in 4.1.0. In earlier versions, use
$HTTP_POST_FILES
.
An associative array of items uploaded 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
$_FILES; to access it within functions or methods, as
you do with $HTTP_POST_FILES
.
$HTTP_POST_FILES
contains the same
information, but is not a superglobal. (Note that
$HTTP_POST_FILES
and $_FILES
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
$_FILES
and $HTTP_POST_FILES
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
Introduced in 4.1.0. There is no equivalent array in earlier versions.
Prior to PHP 4.3.0, $_FILES
information was
also included in $_REQUEST
.
An associative array consisting of the contents of
$_GET
, $_POST
,
and $_COOKIE
.
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 $_REQUEST; to access it within functions or methods.
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
$_REQUEST
array. For related information, see
the security chapter titled Using Register
Globals. These individual globals are not superglobals.
Introduced in 4.1.0. In earlier versions, use
$HTTP_SESSION_VARS
.
An associative array containing session variables available to the current script. See the Session functions documentation for more information on how this is used.
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
$_SESSION; to access it within functions or methods, as
you do with $HTTP_SESSION_VARS
.
$HTTP_SESSION_VARS
contains the same
information, but is not a superglobal. (Note that
$HTTP_SESSION_VARS
and $_SESSION
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
$_SESSION
and $HTTP_SESSION_VARS
arrays. For related information, see the security chapter titled
Using Register
Globals. These individual globals are not superglobals.
$GLOBALS
has been available since PHP 3.0.0.
An associative array containing references to all variables which are currently defined in the global scope of the script. The variable names are the keys of the array.
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 $GLOBALS; to access it within functions or methods.
$php_errormsg
is a variable containing the
text of the last error message generated by PHP. This variable
will only be available within the scope in which the error
occurred, and only if the track_errors configuration
option is turned on (it defaults to off).
$HTTP_RAW_POST_DATA
contains the raw POST data.
See always_populate_raw_post_data
The $http_response_header
array is similiar to the
get_headers() function. When using the
HTTP wrapper
$http_response_header
will be populated with the HTTP
response headers.