I have a problem:
In HTML code, there is a <textarea> and there is a text in it. When I send the content of this <textarea> to the same script and use $_REQUEST for read content, it adds backslashes to quotation-marks ("") ! For exaple I had in HTML:
<form action="(the_same_script)" method="post">
<textarea name="text"> Thing("",""); </textarea>
<input type="submit" value="Send" />
</form>
Later, when I read it with REQUEST (or POST):
echo $_REQUEST["text"];
I receive:
Thing(\"\", \"\");
Please for help.
预定义变量
自 PHP 4.1.0 起,取得外部变量的首选方法是用下面提及的超全局变量。在此之前,人们要么依赖 register_globals,要么就是长长的预定义 PHP 数组($HTTP_*_VARS)。自 PHP 5.0.0 起,长格式的 PHP 预定义变量可以通过设置 register_long_arrays 来屏蔽。
服务器变量:$_SERVER
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_SERVER_VARS。
$_SERVER 是一个包含诸如头信息(header)、路径(path)和脚本位置(script locations)的数组。数组的实体由 web 服务器创建。不能保证所有的服务器都能产生所有的信息;服务器可能忽略了一些信息,或者产生了一些未在下面列出的新的信息。这意味着,大量的这些变量在 » CGI 1.1 规范中说明,所以应该仔细研究一下。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_SERVER; 访问它,就如同使用 $HTTP_SERVER_VARS 一样。
$HTTP_SERVER_VARS 包含着同样的信息,但是不是一个自动全局变量(注意:$HTTP_SERVER_VARS 和 $_SERVER 是不同的变量,PHP 处理它们的方式不同)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_SERVER 和 $HTTP_SERVER_VARS 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
或许会发现下面列出的某些 $_SERVER 元素并不可用。注意,如果以命令行方式运行 PHP,下面列出的元素几乎没有有效的(或是没有任何实际意义的)。
- “PHP_SELF”
- 当前正在执行脚本的文件名,与 document root 相关。举例来说,在 URL 地址为 http://example.com/test.php/foo.bar 的脚本中使用 $_SERVER['PHP_SELF'] 将会得到 /test.php/foo.bar 这个结果。__FILE__ 常量包含当前(例如包含)文件的绝对路径和文件名。 如果 PHP 以命令行方式运行,该变量在 PHP 4.3.0 之前无效。
- “argv”
- 传递给该脚本的参数。当脚本运行在命令行方式时,argv 变量传递给程序 C 语言样式的命令行参数。当调用 GET 方法时,该变量包含请求的数据。
- “argc”
- 包含传递给程序的命令行参数的个数(如果运行在命令行模式)。
- “GATEWAY_INTERFACE”
- 服务器使用的 CGI 规范的版本。例如,“CGI/1.1”。
- “SERVER_ADDR”
- 当前运行脚本所在的服务器的 IP 地址。
- “SERVER_NAME”
- 当前运行脚本所在服务器主机的名称。如果该脚本运行在一个虚拟主机上,该名称是由那个虚拟主机所设置的值决定。
- “SERVER_SOFTWARE”
- 服务器标识的字串,在响应请求时的头信息中给出。
- “SERVER_PROTOCOL”
- 请求页面时通信协议的名称和版本。例如,“HTTP/1.0”。
- “REQUEST_METHOD”
-
访问页面时的请求方法。例如:“GET”、“HEAD”,“POST”,“PUT”。
Note: 如果请求的方式是 HEAD,PHP 脚本将在送出头信息后中止(这意味着在产生任何输出后,不再有输出缓冲)。
- “REQUEST_TIME”
- 请求开始时的时间戳。从 PHP 5.1.0 起有效。
- “QUERY_STRING”
- 查询(query)的字符串(URL 中第一个问号 ? 之后的内容)。
- “DOCUMENT_ROOT”
- 当前运行脚本所在的文档根目录。在服务器配置文件中定义。
- “HTTP_ACCEPT”
- 当前请求的 Accept: 头信息的内容。
- “HTTP_ACCEPT_CHARSET”
- 当前请求的 Accept-Charset: 头信息的内容。例如:“iso-8859-1,*,utf-8”。
- “HTTP_ACCEPT_ENCODING”
- 当前请求的 Accept-Encoding: 头信息的内容。例如:“gzip”。
- “HTTP_ACCEPT_LANGUAGE”
- 当前请求的 Accept-Language: 头信息的内容。例如:“en”。
- “HTTP_CONNECTION”
- 当前请求的 Connection: 头信息的内容。例如:“Keep-Alive”。
- “HTTP_HOST”
- 当前请求的 Host: 头信息的内容。
- “HTTP_REFERER”
- 链接到当前页面的前一页面的 URL 地址。不是所有的用户代理(浏览器)都会设置这个变量,而且有的还可以手工修改 HTTP_REFERER。因此,这个变量不总是真实正确的。
- “HTTP_USER_AGENT”
- 当前请求的 User-Agent: 头信息的内容。该字符串表明了访问该页面的用户代理的信息。一个典型的例子是:Mozilla/4.5 [en] (X11; U; Linux 2.2.9 i586)。也可以使用 get_browser() 得到此信息。
- “HTTPS”
- 如果脚本是通过 HTTPS 协议被访问,则被设为一个非空的值。
- “REMOTE_ADDR”
- 正在浏览当前页面用户的 IP 地址。
- “REMOTE_HOST”
-
正在浏览当前页面用户的主机名。反向域名解析基于该用户的
REMOTE_ADDR。
Note: 必须配置 Web 服务器来建立此变量。例如 Apache 需要在 httpd.conf 中有 HostnameLookups On。参见 gethostbyaddr()。
- “REMOTE_PORT”
- 用户连接到服务器时所使用的端口。
- “SCRIPT_FILENAME”
-
当前执行脚本的绝对路径名。
Note: 如果脚本在 CLI 中被执行,作为相对路径,例如 file.php 或 ../file.php,$_SERVER['SCRIPT_FILENAME'] 将包含用户指定的相对路径。
- “SERVER_ADMIN”
- 该值指明了 Apache 服务器配置文件中的 SERVER_ADMIN 参数。如果脚本运行在一个虚拟主机上,则该值是那个虚拟主机的值。
- “SERVER_PORT”
- 服务器所使用的端口。默认为“80”。如果使用 SSL 安全连接,则这个值为用户设置的 HTTP 端口。
- “SERVER_SIGNATURE”
- 包含服务器版本和虚拟主机名的字符串。
- “PATH_TRANSLATED”
-
当前脚本所在文件系统(不是文档根目录)的基本路径。这是在服务器进行虚拟到真实路径的映像后的结果。
Note: PHP 4.3.2 之后,PATH_TRANSLATED 在 Apache 2 SAPI 模式下不再和 Apache 1 一样隐含赋值,而是若 Apache 不生成此值,PHP 便自己生成并将其值放入 SCRIPT_FILENAME 服务器常量中。这个修改遵守了 CGI 规范,PATH_TRANSLATED 仅在 PATH_INFO 被定义的条件下才存在。 Apache 2 用户可以使用 httpd.conf 中的 AcceptPathInfo On 来定义 PATH_INFO。
- “SCRIPT_NAME”
- 包含当前脚本的路径。这在页面需要指向自己时非常有用。__FILE__ 包含当前文件的绝对路径和文件名(例如包含文件)。
- “REQUEST_URI”
- 访问此页面所需的 URI。例如,“/index.html”。
- “PHP_AUTH_DIGEST”
- 当作为 Apache 模块运行时,进行 HTTP Digest 认证的过程中,此变量被设置成客户端发送的“Authorization”HTTP 头内容(以便作进一步的认证操作)。
- “PHP_AUTH_USER”
- 当 PHP 运行在 Apache 或 IIS(PHP 5 是 ISAPI)模块方式下,并且正在使用 HTTP 认证功能,这个变量便是用户输入的用户名。
- “PHP_AUTH_PW”
- 当 PHP 运行在 Apache 或 IIS(PHP 5 是 ISAPI)模块方式下,并且正在使用 HTTP 认证功能,这个变量便是用户输入的密码。
- “AUTH_TYPE”
- 当 PHP 运行在 Apache 模块方式下,并且正在使用 HTTP 认证功能,这个变量便是认证的类型。
环境变量:$_ENV
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_ENV_VARS。
在解析器运行时,这些变量从环境变量转变为 PHP 全局变量名称空间(namespace)。它们中的许多都是由 PHP 所运行的系统决定。完整的列表是不可能的。请查看系统的文档以确定其特定的环境变量。
其它环境变量(包括 CGI 变量),无论 PHP 是以服务器模块或是以 CGI 处理方式运行,都在这里列出了。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_ENV; 来访问它,就如同使用 $HTTP_ENV_VARS 一样。
$HTTP_ENV_VARS 包含着同样的信息,但是不是一个自动全局变量(注意:$HTTP_ENV_VARS 和 $_ENV 是不同的变量,PHP 处理它们的方式不同)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_ENV 和 $HTTP_ENV_VARS 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
HTTP GET 变量:$_GET
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_GET_VARS。
通过 HTTP GET 方法传递的变量组成的数组。是自动全局变量。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_GET; 来访问它,就如同使用 $HTTP_GET_VARS 一样。
$HTTP_GET_VARS 包含着同样的信息,但是不是一个自动全局变量(注意:$HTTP_GET_VARS 和 $_GET 是不同的变量,PHP 处理它们的方式不同)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_GET 和 $HTTP_GET_VARS 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
HTTP POST 变量:$_POST
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_POST_VARS。
通过 HTTP POST 方法传递的变量组成的数组。是自动全局变量。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_POST; 来访问它,就如同使用 $HTTP_POST_VARS 一样。
$HTTP_POST_VARS 包含着同样的信息,但是不是一个自动全局变量(注意:$HTTP_POST_VARS 和 $_POST 是不同的变量,PHP 处理它们的方式不同)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_POST 和 $HTTP_POST_VARS 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
HTTP 文件上传变量:$_FILES
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_POST_FILES。
通过 HTTP POST 方法传递的已上传文件项目组成的数组。是自动全局变量。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_FILES; 来访问它,就如同使用 $HTTP_POST_FILES 一样。
$HTTP_POST_FILES 包含着同样的信息,但是不是一个自动全局变量(请注意 PHP 是把 $HTTP_POST_FILES 和 $_FILES 这两个变量当作不同的变量来处理的)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_FILES 和 $HTTP_POST_FILES 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
Request 变量:$_REQUEST
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,没有等价的数组。
Note: 在 PHP 4.3.0 之前,$_FILES 也被包括在 $_REQUEST 数组中。
此关联数组包含 $_GET,$_POST 和 $_COOKIE 中的全部内容。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味着它在所有的脚本中都有效。在函数或方法中不需要使用 global $_REQUEST; 来访问它。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_REQUEST 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
Session 变量:$_SESSION
Note: 在 PHP 4.1.0 及以后版本使用。之前的版本,使用 $HTTP_SESSION_VARS。
包含当前脚本中 session 变量的数组。参阅 Session 函数文档以获得更多信息。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $_SESSION; 来访问它,就如同使用 $HTTP_SESSION_VARS 一样。
$HTTP_SESSION_VARS 包含着同样的信息,但是不是一个自动全局变量(请注意 PHP 是把 $HTTP_SESSION_VARS 和 $_SESSION 这两个变量当作不同的变量来处理的)。
如果设置了 register_globals 指令,这些变量也在所有脚本中可用;也就是,分离了 $_SESSION 和 $HTTP_SESSION_VARS 数组。相关信息,请参阅安全的相关章节使用 Register Globals。这些单独的全局变量不是自动全局变量。
Global 变量:$GLOBALS
Note: $GLOBALS 在 PHP 3.0.0 及以后版本中适用。
由所有已定义全局变量组成的数组。变量名就是该数组的索引。
这是一个“superglobal”,或者可以描述为自动全局变量。这只不过意味这它在所有的脚本中都有效。在函数或方法中不需要使用 global $GLOBALS; 来访问它。
前一个错误消息:$php_errormsg
$php_errormsg 是包含 PHP 产生的上一错误消息内容的变量。该变量在发生错误并且 track_errors 选项打开(默认为关闭)后才有效。
预定义变量
29-Apr-2008 02:19
08-Apr-2008 12:15
When using a php script like a remote function call, I find something like this useful for setting default parameters.
<?php
/**
/* combine _GET _POST _COOKIE variables with provided default values
/* defaults - associative array of default values
/* overwrite - if true, write result to _REQUEST superglobal
/* super_globals - array of super globals to fetch values from
**/
function get_params($defaults = null, $overwrite = false, $super_globals = array('_GET', '_POST', '_COOKIE'))
{
$ret = array();
// fetch values from request
foreach($super_globals as $sg)
foreach($GLOBALS[$sg] as $k=>$v)
$ret[$k] = $v;
// apply defaults for missing parameters
if($defaults) foreach($defaults as $k=>$v)
if(!isset($ret[$k]))
$ret[$k] = $v;
if($overwrite)
$_REQUEST = $ret;
return $ret;
}
// Example: page.php?style=modern
$argv = get_params(array('id'=>42, 'style'=>'medieval'));
// $argv['id'] = 42
// $argv['style'] = 'modern'
?>
19-Feb-2008 07:56
Note the manual entry for PHP_SELF states the following:
"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."
However I did some vigorous testing on three different machines and this note is not always true. The results are given below:
Given a URL of http://www.example.com/Info.php/Page/Home
Apache 2.2.4/Win32/PHP 5.2.2/Apache 2.0 Handler
----> PHP_SELF = Info.php/Page/Home
Apache 1.3.37/Unix/PHP 5.2.2/CGI
----> PHP_SELF = Info.php
Apache 1.3.33/Unix/5.1.4/FastCGI
----> PHP_SELF = Info.php
To be completely honest, I am not sure why this is the case; perhaps there is a setting in Apache to modify this option, but in either case take careful consideration of this note.
13-Feb-2008 10:15
I was a little frustrated by the fact that some of the _SERVER variables didn't seem to exist, so I did a bit of Googling and found the answer: many of these variables are supplied by the web server and not all web servers supply the same set of variables.
I found a comparison between Apache v1.3.29 and IIS v5.1 on this page: http://koivi.com/apache-iis-php-server-array.php Useful for those of us doing cross-platform development.
While running experiments with different browsers I noticed some of the HTTP_* variables come and go depending on the browser used, or in the case of Opera by diddling the "user mode" (the widget that lets you look at a page as text only, etc.). For example: in IE and Opera HTTP_KEEP_ALIVE was missing, but was present in Firefox and Mozilla, and when I fiddled with Opera's "user mode" I got somethings called HTTP_TE and HTTP_CACHE_CONTROL.
So, what you get is dependent on the web server AND the browser.
I did see one IIS supplied variable not on that list: REQUEST_TIME, which seems to be in Unix timestamp format.
While researching this I discovered there are plenty of people who have their phpinfo() page visible and indexed on a few search engines. For those who want to dig a bit deeper than that nice web page comparing Apache to IIS, looking at other peoples' phpinfo() pages could be useful. You get the version of PHP plus OS and web server they use, along with all the _SERVER variables. I found the highest percent of signal-to-noise by searching for "phpinfo()" (with the quotes) on Dogpile: http://www.dogpile.com/
14-Dec-2007 12:40
In addition to mfyahya at gmail dot com (2007-06-07 03:33):
If You are working with the Apache module mod_rewrite and want to set some environment vars, the Apache manual says this vars could be accessed in CGI using $ENV{VAR}. In PHP You might want to write $_ENV['VAR'] to get the value of VAR, but You have to access if via $_SERVER, and in some different ways:
1. Example: .htaccess and example.php
RewriteEngine on
RewriteRule ^?var1=([^;]*);var2=([^;]*)$ \
- [E=VAR1:$1,E=VAR2:$2]
<?php echo($_SERVER['VAR1']."\r\n"
.$_SERVER['VAR2']); ?>
2. Example: .htaccess and index.php
RewriteEngine on
RewriteRule ^index\.php$ - [L]
RewriteRule ?var1=([^;]*);var2=([^;]*)$ \
index.php [E=VAR1:$1,E=VAR2:$2]
<?php echo($_SERVER['REDIRECT_VAR1']."\r\n"
.$_SERVER['REDIRECT_VAR2']); ?>
Note: If any RewriteRule matches, an internal redirect than restarts (after the last defined rule, or immediately after the matched rule having a L-flag) checking the entire rule set again. For an internal redirect every defined VAR gets an 'REDIRECT_' prefix, i.e. VAR1 will be REDIRECT_VAR1, VAR2 will be REDIRECT_VAR2.
Of course, You can (additionally) redefine the original VAR:
RewriteEngine on
RewriteRule ^index\.php$ \
- [E=VAR1:%{REDIRECT_VAR1},E=VAR2:%{REDIRECT_VAR2},L]
RewriteRule ?var1=([^;]*);var2=([^;]*)$ \
index.php [E=VAR1:$1,E=VAR2:$2]
With this, You will have $_SERVER['REDIRECT_VAR*'] -and- $_SERVER['VAR*'].
***
The given examples are only for explanation, in any case they are not intended to fit Your needs. The "\<CRLF><SP>" in the .htaccess examples are only for display purpose, they should not occur in a real .htaccess file. The argument separator ';' in links can also be '&', but this may cause some trouble with HTML/XHTML. See the following pages for more information about this issue:
- http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
- http://www.w3.org/QA/2005/04/php-session
23-Nov-2007 03:49
SECURITY RISK !
Never ever trust the values that comes from $_SERVER.
HTTP_X_FORWARDED, HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR, HTTP_FORWARDED, etc.. can be spoofed !
To get the ip of user, use only $_SERVER['REMOTE_ADDR'], otherwise the 'ip' of user can be easily changed by sending a HTTP_X_* header, so user can escape a ban or spoof a trusted ip.
Of course this is well know, but I don't see it mentioned in these notes..
If you use the ip only for tracking (not for any security features like banning or allow access to something by ip), you can also use HTTP_X_FORWARDED to get user's ip what are behind proxy.
15-Nov-2007 02:03
In response to mathiasrav's getip() implementation on 28-Jul-2007, it should be noted that it:
- assumes IPv4 addresses only
- returns $_SERVER['REMOTE_ADDR'] for any value of $_SERVER['HTTP_CLIENT_IP'] that matches 127.0.*.*, 192.168.*.* or 10.0.*.*, which is not desirable if you actually WANT the value of HTTP_CLIENT_IP
dlyaza's prior snippet has neither of these problems.
01-Nov-2007 10:59
Note that some headers will be checked for validity (by Apache, I suppose) before showing up in $_SERVER -- If-Modified-Since for example.
<?php
$lastmod = gmdate('D, d M Y H:i:s', filemtime('somefile'));
header("Last-Modified: $lastmod");
?>
This WON'T work, "GMT" is missing. Internet Explorer auto-fixes this by adding GMT, while Firefox resends this data as-is. (So an If-Modified-Since-header is sent, but neither shows up in $_SERVER nor in apache_request_headers()). This would be correct:
<?php
$lastmod = gmdate('D, d M Y H:i:s', filemtime('somefile')) . 'GMT';
header("Last-Modified: $lastmod");
?>
20-Oct-2007 03:39
@White-Gandalf: one can control this behavior by setting:
UseCanonicalName On|Off
in their apache config (at least, on *ix platforms).
On => $_SERVER['SERVER_NAME'] is the ServerName var from either the global server or virtual host, whichever wraps the PHP app closest.
Off => Whatever was in the Host: header sent by the client.
16-Oct-2007 10:01
'SERVER_NAME' does NOT necessarily refer to the name of a virtual host or any other things defined in the apache config.
Instead it simply takes the value of the "Host:" entry of the HTTP-header sent by the client.
At least with apache version 2.2.5 on Windows.
21-Sep-2007 11:45
The headers sent by the browser will be stored in the $_SERVER array -- they will get capitalized and prefixed with HTTP. So a header like "X-Foo-Bar: Baz" will result in <?php $_SERVER['HTTP_X_FOO_BAR'] = 'Baz';?>. This is why you should use isset before using e.g. HTTP_ACCEPT_LANGUAGE, 'cause it may not be set.
The only exception I know from that is HTTP_X_ORIGINAL_URI, which is always set and holds the current URL without querystring. But you can't trust that too because it can be overriden by sending a X-Original-URI header.
06-Aug-2007 12:41
To get the directory of the current script: (I think this is a little more resource-friendly, but then again with all the fast computers available, it does not matter so much...)
<?
// For the script that is running:
$script_directory = substr($_SERVER['SCRIPT_FILENAME'], 0, strrpos($_SERVER['SCRIPT_FILENAME'], '/'));
// If your script is included from another script:
$included_directory = substr(__FILE__, 0, strrpos(__FILE__, '/'));
echo $script_directory . '<br />';
echo $included_directory . '<br />';
?>
If you have a script that only includes the script written above in a directory called 'includer', and I access it from a web browser, this will be what I see:
/path/to/includer/
/path/to/included/
11-Apr-2007 10:37
If you're working with $_GET a lot and need to preserve already set variables in a link for the next page, this function is pretty handy for simplifying the process of generating a new URL:
string setUrlVariables([string var, string value], [varN, valueN], ...)
<?php
function setUrlVariables() {
$arg = array();
$string = "?";
$vars = $_GET;
for ($i = 0; $i < func_num_args(); $i++)
$arg[func_get_arg($i)] = func_get_arg(++$i);
foreach (array_keys($arg) as $key)
$vars[$key] = $arg[$key];
foreach (array_keys($vars) as $key)
if ($vars[$key] != "") $string.= $key . "=" . $vars[$key] . "&";
if (SID != "" && SID != "SID" && $_GET["PHPSESSID"] == "")
$string.= htmlspecialchars(SID) . "&";
return htmlspecialchars(substr($string, 0, -1));
}
?>
You use it like this:
<a href="nextpage.php<?php echo setUrlVariables(); ?>">Link</a>
In this case setUrlVariables() will simply add all the $_GET variables of the current page/URL and even takes care of the PHPSESSID if you use one (and didn't change the default variable name). The above HREF would complete to e.g.:
"nextpage.php?var=21&PHPSESSID=BI89J"
If you supply arguments, do it like this:
<?php echo setUrlVariables("user", "foobar"); ?>
This would complete the HREF to e.g.:
"nextpage.php?user=foobar&var=21&PHPSESSID=BI89J"
Unsetting variables works by supplying an empty value:
<?php echo setUrlVariables("var", ""); ?>
"nextpage.php?user=foobar&PHPSESSID=BI89J"
setUrlVariables() also makes sure it produces "pretty URLs", so it doesn't output any unnecessary garbage. ;)
<?php
session_destroy();
echo setUrlVariables("user", "");
?>
"nextpage.php"
22-Mar-2007 04:22
If you have problems with $_SERVER['HTTPS'], especially if it returns no values at all you should check the results of phpinfo(). It might not be listed at all.
Here is a solution to check and change, if necessary, to ssl/https that will work in all cases:
<?php
if ($_SERVER['SERVER_PORT']!=443) {
$sslport=443; //whatever your ssl port is
$url = "https://". $_SERVER['SERVER_NAME'] . ":" . $sslport . $_SERVER['REQUEST_URI'];
header("Location: $url");
}
?>
Of course, this should be done before any html tag or php echo/print.
25-Jan-2007 03:53
I think it is very important to note that PHP will automatically replace dots ('.') AND spaces (' ') with underscores ('_') in any incoming POST or GET (or REQUEST) variables.
This page notes the dot replacement, but not the space replacement:
http://us2.php.net/manual/en/language.variables.external.php
The reason is that '.' and ' ' are not valid characters to use in a variable name. This is confusing to many people, because most people use the format $_POST['name'] to access these values. In this case, the name is not used as a variable name but as an array index, in which those characters are valid.
However, if the register_globals directive is set, these names must be used as variable names. As of now, PHP converts the names for these variables before inserting them into the external variable arrays, unfortunately - rather than leaving them as they are for the arrays and changing the names only for the variables set by register_globals.
If you want to use:
<input name="title for page3.php" type="text">
The value you will get in your POST array, for isntance would be:
$_POST['title_for_page3_php']
18-Nov-2006 10:22
The *only* way to make Request_URI work as a 100% Apache-Compliant server variable on IIS/Windows is to use an Isapi Filter - as documented at http://neosmart.net/blog/archives/291 . The various steps mentioned below *completely* fail when a rewrite engine is employed, since IIS will *never* return a non-existent path (i.e. the actual pretty-URI used) via its server variables.
This also applies to accessing index.php via a folder.
For instance, calls made to /folder/ will appear as /folder/index.php and not /folder/.
The fix is to use the ISAPI filter provided at http://neosmart.net/blog/archives/291
You don't have to modify any of the actual scripts once this filter is in place - it automatically intercepts calls to REQUEST_URI and replaces them with the actual user-entered path.
10-Nov-2006 12:59
I'm sure this is elsewhere, but since 'chris dot chaudruc at gmail dot com' posted his example, I thought I would share a quick function I use to force HTTPS protocol on a page, without having to know the scripts name...
<?php
function ForceHTTPS()
{
if( $_SERVER['HTTPS'] != "on" )
{
$new_url = "https://" . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
header("Location: $new_url");
exit;
}
}
?>
Correct me if part of this doesn't work right. I've always used *nix based servers for PHP, so I might not be aware of certain windows limitations. Thanks.
19-Sep-2006 05:16
If you want to use a form with multiple checkboxes (e.g. one per row) and assign the same name to each checkbox then the name needs to end with []. This tells PHP to put all checked values into an array variable.
For example:
<input type="checkbox" name="id[]" value="value_1">
<input type="checkbox" name="id[]" value="value_2">
..
<input type="checkbox" name="id[]" value="value_x">
You can now retrieve all values by using:
$values = $_POST['id'];
If the name does not end with [], then only a single value will be available via the $_POST variable even if the user checks several checkboxes.
06-May-2006 03:19
Refer to CanonicalName if you are not getting the ServerName in the $_SERVER[SERVER_NAME] variable....This was a pain to figure out for me...now it works as expected by turning canonical naming on.
http://www.apacheref.com/ref/http_core/UseCanonicalName.html
26-Apr-2006 10:24
Be careful with HTTP_HOST behind a proxy server. Use these instead.
[HTTP_X_FORWARDED_FOR]
[HTTP_X_FORWARDED_HOST]
[HTTP_X_FORWARDED_SERVER]
In my situation, I used [HTTP_X_FORWARDED_SERVER] in place of [HTTP_HOST] in order get the machine and hostname (www.myurl.com)
14-Apr-2006 09:18
So you have an application in your web space, with a URL such as this:
http://<host>/<installation_path>/
and pages such as
http://<host>/<installation_path>/subfolder1/subfolder2/page.php
You have a file called config.php in <installation_path> which is include()d by all pages (in subfolders or not).
How to work out <installation_path> without hard-coding it into a config file?
<?php
// this is config.php, and it is in <installation_path>
// it is included by <installation_path>/page.php
// it is included by <installation_path>/subfolder/page2.php
// etc
$_REAL_SCRIPT_DIR = realpath(dirname($_SERVER['SCRIPT_FILENAME'])); // filesystem path of this page's directory (page.php)
$_REAL_BASE_DIR = realpath(dirname(__FILE__)); // filesystem path of this file's directory (config.php)
$_MY_PATH_PART = substr( $_REAL_SCRIPT_DIR, strlen($_REAL_BASE_DIR)); // just the subfolder part between <installation_path> and the page
$INSTALLATION_PATH = $_MY_PATH_PART
? substr( dirname($_SERVER['SCRIPT_NAME']), 0, -strlen($_MY_PATH_PART) )
: dirname($_SERVER['SCRIPT_NAME'])
; // we subtract the subfolder part from the end of <installation_path>, leaving us with just <installation_path> :)
?>
03-Apr-2006 05:11
To convert query string parameter values ($_GET, $_REQUEST), which include escaped Unicode values resulting from applying the JavaScript "escape" function to a Unicode string (%uNNNN%uNNNN%uNNNN) fast and simple is to use PECL JSON extension:
function JavaScript_Unicode_URL_2_Str($js_uni_str) {
$res = preg_replace('/%u([[:alnum:]]{4})/', '\\u\1', $js_uni_str);
$res = str_replace('"', '\"', $res); // if in str "
$res = json_decode('["'.$res.'"]'); // JavaScrip array with string element
$res = $res[0];
$res = iconv('UTF-8', ini_get('default_charset'), $res);
return $res;
}
I was unable to convince my hosting company to change their installation of PHP and therefore had to find my own way to computer $_SERVER["DOCUMENT_ROOT"]. I eventually settled on the following, which is a combination of earlier notes (with some typos corrected):
<?php
if ( ! isset($_SERVER['DOCUMENT_ROOT'] ) )
$_SERVER['DOCUMENT_ROOT'] = str_replace( '\\', '/', substr(
$_SERVER['SCRIPT_FILENAME'], 0, 0-strlen($_SERVER['PHP_SELF']) ) );
?>
30-Mar-2006 05:24
Note that PHP_SELF will not be equal to REQUEST_URI under Apache if mod_rewrite has been used to move one URL to another--PHP_SELF will contain the rewritten address, and REQUEST_URI will contain the URL the user sees in their browser.
08-Mar-2006 05:35
$_GET may not handle query string parameter values which include escaped Unicode values resulting from applying the JavaScript "escape" function to a Unicode string.
To handle this the query parameter value can be obtained using a function such as:
function getQueryParameter ($strParam) {
$aParamList = explode('&', $_SERVER['QUERY_STRING']);
$i = 0;
while ($i < count($aParamList)) {
$aParam = split('=', $aParamList[$i]);
if ($strParam == $aParam[0]) {
return $aParam[1];
}
}
return "";
}
or by directly building an array or query string values and then processing the parameter string using a function such as the "unescape" function which can be found at http://www.kanolife.com/escape/2006/03/unicode-url-escapes-in-php.html (or http://www.kanolife.com/escape/ for related info).
01-Mar-2006 04:00
Note that it's a very, very bad idea to append to global variables in a loop, unless you really, really mean to do so in a global context. I just a while ago hung my server with a snippet of code like this:
<?php
$host = $_SERVER['HTTP_HOST'];
$uri = rtrim($_SERVER['PHP_SELF'], "/\\");
$GLOBALS['SITE_ROOT'] = "http://$host$uri";
while ($i < somenumber)
readfile($GLOBALS['SITE_ROOT'] = $GLOBALS['SITE_ROOT'] . '/this/file.php');
$i++
}
?>
While it is an entertaining and unusual method of creating very long URLs and breaking servers, it's a pretty awesomely bad idea
(Especially considering that the script in question ran concurrently with others of it's type, so the value in $GLOBALS['SITE_ROOT'] was unknown.)
23-Feb-2006 12:05
Also on using IPs to look up country & city, note that what you get might not be entirely accurate. If their ISP is based in a different city or province/state, the IPs may be owned by the head office, and used across several areas.
You also have rarer situations where they might be SSHed into another server, on the road, at work, at a friend's... It's a nice idea, but as the example code shows, it should only be used to set defaults.
20-Jan-2006 12:05
The solution advanced by info at meshkaat dot com does not work correctly on machines with IIS configured to use
a virtual directory as the launch point. The address strings for $_SERVER['SCRIPT_FILENAME'] and $_SERVER['PHP_SELF'] will not necessarily have the same name for the highest level directory in $_SERVER['PHP_SELF'], and therefore this solution will not return the proper value.
12-Jan-2006 11:57
Under Windows XP SP2 and IIS, $_SERVER('x') returns a path using forward slash '/' as the separator, where x is:
PHP_SELF, SCRIPT_NAME
These arguments, however, all return a path using backward slash, '\' as the separator:
__FILE__, SCRIPT_FILENAME, and DOCUMENT_ROOT (if you use one of the methods mentioned previously).
Also note that if the name of the last directory in the document root includes a space, the methods described above for setting DOCUMENT_ROOT will return a value that drops the everything past the space.
30-Nov-2005 11:17
Since $_SERVER['DOCUMENT_ROOT'] is not always present, the following will provide it where $_SERVER dosen't.
<?php
function resolveDocumentRoot() {
$current_script = dirname($_SERVER['SCRIPT_NAME']);
$current_path = dirname($_SERVER['SCRIPT_FILENAME']);
/* work out how many folders we are away from document_root
by working out how many folders deep we are from the url.
this isn't fool proof */
$adjust = explode("/", $current_script);
$adjust = count($adjust)-1;
/* move up the path with ../ */
$traverse = str_repeat("../", $adjust);
$adjusted_path = sprintf("%s/%s", $current_path, $traverse);
/* real path expands the ../'s to the correct folder names */
return realpath($adjusted_path);
}
?>
It counts the number of folders down the path we are in the URL, then moves that number of folders up the current path... end result should be the document root :)
It wont work with virtual folders or in any situation where the folder in the URL dosen't map to a real folder on the disk (like when using rewrites).
11-Oct-2005 11:01
In response to tobias at net-clipping dot de
It is not an Apache bug. Please read http://httpd.apache.org/docs/2.1/mod/core.html#errordocument carefully (2.1 version here, 2.0 and 1.x is similar).
In short, if your ErrorDocument start with http:// Apache sends a redirect (302) to the error document, hence losing your original referer. If your ErrorDocument points to a relative path, 404 is maintained and so are your variables.
From the Apache manual:
"Note that when you specify an ErrorDocument that points to a remote URL (ie. anything with a method such as http in front of it), Apache will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code. In addition, if you use a remote URL in an ErrorDocument 401, the client will not know to prompt the user for a password since it will not receive the 401 status code. Therefore, if you use an ErrorDocument 401 directive then it must refer to a local document."
D.
30-Sep-2005 11:51
Re: You can take advantage of 404 error to an usable redirection using REQUEST_URI ...
Whilst this is effective, a line in the .htaccess such as:
RewriteEngine On
RewriteRule ^profiles/([A-Za-z0-9-]+) showprofile.php?profile=$1 [L,NC,QSA]
will throw the requested profile in a variable $profile to the showprofile.php page.
You can further enhance the url (e.g http://servername/profiles/Jerry/homeaddress/index.htm) and the second variable value homeaddress becomes available in $url_array[3] when used below $url_array=explode("/",$_SERVER['REQUEST_URI']);
Hope this helps - Works well for me
Drew
04-Aug-2005 11:55
Warning:
$_SERVER['PHP_SELF'] and $_SERVER['SCRIPT_NAME'] may not always be set correctly.
Some web hosts implement php as a CGI in such a way that they can turn it on or off for each virtual domain. Several $_SERVER and $_ENV variable values may be incorrect for documents in subdirectory subdomains of these virtual domains.
An include-file function or constant, instead of PHP_SELF or some other predefined variable throughout a website, will make it easier to "fix" an entire website in case something changes.
<?php
function true_url_path() {
// Pick the predefined variable that works on your server
return $_ENV['SCRIPT_URL'];
}
?>
Or
<?php
// Pick the predefined variable that works on your server
define("TRUE_URL_PATH", $_ENV['SCRIPT_URL']);
?>
31-Jul-2005 05:41
$_SERVER['QUERY_STRING']
Does not contain XHTML 1.1 compliant ampersands i.e. &
So you will need to do something like this if you are to use $_SERVER['QUERY_STRING'] in URL's.
// XHTML 1.1 compliant ampersands
$_SERVER['QUERY_STRING'] =
str_replace(array('&', '&'), array('&', '&'),
$_SERVER['QUERY_STRING']);
24-Jul-2005 09:59
Warning: $_SERVER['PHP_SELF'] can include arbitrary user input. The documentation should be updated to reflect this.
The request "http://example.com/info.php/attack%20here" will run /info.php, but in Apache $_SERVER['PHP_SELF'] will equal "/info.php/attack here". This is a feature, but it means that PHP_SELF must be treated as user input.
The attack string could contain urlencoded HTML and JavaScript (cross-site scripting) or it could contain urlencoded linebreaks (HTTP response-splitting).
The use of $_SERVER['SCRIPT_NAME'] is recommended instead.
16-Jul-2005 02:43
Note that $php_errormsg may contain a newline character. This can be problematic if you are trying to output it with a JavaScript "alert()" for example.
06-Jul-2005 09:22
I wanted to be able to embed a variable in the path. This is useful when, for example, images are rendered on the fly and you would like them to have different urls.
Here is an illustration:
www.somesite.com/image.php/IMAGETEXTHERE
This would return an image with the text after "image.php/" contained in it.
I could not recall the name of this feature, so I made a work-around in PHP...
<?
function getPathVariables() {
$sPathPS = $_SERVER[PHP_SELF];
$sPathFS = __FILE__;
$aPathPS = array_reverse(explode("/", $sPathPS));
$aPathFS = array_reverse(explode("/", $sPathFS));
$aImageArgs = array();
$x = 0;
while ( $aPathPS[$x] != $aPathFS[$x] && $aPathPS[$x] != $aPathFS[0] ) {
array_unshift($aImageArgs, $aPathPS[$x]) ;
$x++;
}
return $aImageArgs;
}
?>
This function will return an array containing each "/" delimited portion of the path after the script name itself.
27-Jun-2005 10:14
Note that $_SERVER['QUERY_STRING'] behaves differently under IIS/Apache.
In Apache (at least on Windows) it is ALWAYS set - if no query string was specified in the URL, $_SERVER['QUERY_STRING'] is initialised as an empty string.
In IIS, if no query string is included in the URL, $_SERVER['QUERY_STRING'] is NOT SET, so trying to access it without checking for its existence will generate notices.
14-Jun-2005 04:03
A note about the QUERY_STRING variable when using IIS:
I have found that IIS does not handle large query strings gracefully when passed from PHP. In addition to truncating them to around 1024 kb, I have seen IIS actually add data from other server variables to the end of the truncated data.
This occurred on Windows 2000 server running IIS 5.0 and PHP 4.3.8. The problem did not occur when handled by Apache, even on another Windows server.
Note: I realize passing this much data is best accomplished using the POST method, which would avoid this problem all together. I'm merely detailing a problem that I came across.
I have created a page that includes the (very long) query string that was used and some of the results that I saw while testing. It can be viewed at http://www.csb7.com/test/php_iis_qs_limit/. I didn't want to include it here as it would stretch the page out significantly.
~Chris Bloom
07-Jun-2005 09:33
If you use Apache's redirection features for custom error pages or whatever, the following Apache's REDIRECT variables are also available in $_SERVER:
$_SERVER['REDIRECT_UNIQUE_ID]'
$_SERVER['REDIRECT_SCRIPT_URL]'
$_SERVER['REDIRECT_SCRIPT_URI]'
$_SERVER['REDIRECT_SITE_ROOT]'
$_SERVER['REDIRECT_SITE_HTMLROOT]'
$_SERVER['REDIRECT_SITE_CGIROOT]'
$_SERVER['REDIRECT_STATUS]'
$_SERVER['REDIRECT_QUERY_STRING]'
$_SERVER['REDIRECT_URL]'
I'm not sure if this is a complete list though
07-May-2005 02:23
With the arrival of the Google Web Accelerator, the problem of keeping track of users through $_SERVER['REMOTE_ADDR'] (for a much shorter while than with cookies) has reared its ugly head anew.
For those confronted with this issue, remember that Google implements the $_SERVER['HTTP_X_FORWARDED_FOR'] header giving the IP address of the connection that it proxies.
Hope this helps...
13-Apr-2005 09:23
Under Windows 2000, running IIS and PHP 4.3.10, $_SERVER['SCRIPT_NAME'] is not available, however $_SERVER['SCRIPT_FILENAME'] is present and seems to contain the same information.
Matt Johnson says that one should never urldecode() $_GET data. This is incorrect.
If magic_quotes_gpc is turned off in php.ini, then you *do* need to urldecode() $_GET data.
Having magic_quotes_gpc turned off is considered good practise.
14-Feb-2005 08:19
The Environment variable $ENV is useful for coding portable platform specific application constants.
// Define a Windows or else Linux root directory path
$_ENV['OS'] == 'Windows_NT' ? $path = 'L:\\www\\' : $path = ' /var/www/';
define('PATH', $path);
echo PATH;
12-Feb-2005 11:09
Sorry if this is old news to some, but it might not be obvious at a first glance:
If you are using $_SERVER['remote_addr'] as a way to keep track of a logged-in user (this can be useful to avoid several types of hacking), remember that it might not be the user's actual IP address!
I was trying to implement a login feature that used this, storing the IP into a DB. It went smoothly while on a LAN, but wrecked havoc when accepting outter connections.
27-Jan-2005 04:51
If your having problems returning $_SERVER variables using apache, be sure you enable:
ExtendedStatus On
in your httpd.conf file.
If it's off, then things like $_SERVER['HTTP_HOST'] won't be present.
24-Jan-2005 08:02
The variable $php_errormsg is not populated if you have XDebug running.
10-Jan-2005 05:26
Running Xitami in Windows 2000 and PHP 4.3.7, nor PHP_SELF or SCRIPT_FILENAME is not availiable. Trying SCRIPT_NAME instead. Here is a function that returns the filename of a script without slashes. Good for use in HTML FORM ACTION=""-arguments...
function getThisFile() {
/* try to use PHP_SELF first... */
if (!empty($_SERVER['PHP_SELF'])) {
$strScript = $_SERVER['PHP_SELF'];
/* otherwise, try SCRIPT_NAME */
} else if (!empty($_SERVER['SCRIPT_NAME'])) {
$strScript = @$_SERVER['SCRIPT_NAME'];
/* last resort - quit out and return nothing */
} else {
return null;
}
/* fint last frontslash in filename */
$intLastSlash = strrpos($strScript, "/");
/* check if last backslash is more far away in filename */
if (strrpos($strScript, "\\")>$intLastSlash) {
/* if so, use the backslash position instead */
$intLastSlash = strrpos($strScript, "\\");
}
/* cut out from the last slash and to the end of the filename */
return substr($strScript, $intLastSlash+1, strlen($strScript));
}
Tested on PHP 4.3.7/Win32 and PHP 5.0.3/Linux.
You may add more filepaths to the first if-section
to get more chances to catch up the filename if you can.
26-Dec-2004 08:50
A reminder: if you are considering using urldecode() on a $_GET variable, DON'T!
Evil PHP:
<?php
# BAD CODE! DO NOT USE!
$term = urldecode($_GET['sterm']);
?>
Good PHP:
<?php
$term = $_GET['sterm'];
?>
The webserver will arrange for $_GET to have been urldecoded once already by the time it reaches you!
Using urldecode() on $_GET can lead to extreme badness, PARTICULARLY when you are assuming "magic quotes" on GET is protecting you against quoting.
Hint: script.php?sterm=%2527 [...]
PHP "receives" this as %27, which your urldecode() will convert to "'" (the singlequote). This may be CATASTROPHIC when injecting into SQL or some PHP functions relying on escaped quotes -- magic quotes rightly cannot detect this and will not protect you!
This "common error" is one of the underlying causes of the Santy.A worm which affects phpBB < 2.0.11.
19-Oct-2004 11:13
Nothing about the message-body ...
You can get cookies, session variables, headers, the request-uri , the request method, etc but not the message body. You may want it sometimes when your page is to be requested with the POST method.
Maybe they should have mentioned $HTTP_RAW_POST_DATA or php://stdin
06-Sep-2004 03:21
Using Apache/mod_ssl, there are further environment variables available to check for an SSL connection (can be more useful than $_SERVER['SERVER_PORT']), documented here: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25
To test whether the client connected with SSL I can use $_SERVER['HTTPS'] e.g (with redirect to secured, current URL);
<?php
if ( !isset($_SERVER['HTTPS']) || strtolower($_SERVER['HTTPS']) != 'on' ) {
header ('Location: https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
exit();
}
?>
30-Aug-2004 10:13
You can add $_SERVER["DOCUMENT_ROOT"] to IIS by editing the Environment Variables of your Windows server (was tested on WinXP SP2).
Right click on My Computer >> Properties >> Advanced.
In the System variables click on 'New' and Type in the name field 'DOCUMENT_ROOT' and in the value field the path to your IIS document root folder.
Don't forget to restart your Windows (IIS restart won't load the new settings).
12-May-2004 08:34
$_SERVER['DOCUMENT_ROOT'] *is* supported by IIS, although only when running PHP as an ISAPI module.
06-Apr-2004 12:20
Be carful when using $_SERVER['DOCUMENT_ROOT']; in your applications where you want to distribute them to other people with different server types. It isnt always supported by the webserver (IIS).
19-Dec-2003 01:32
The RAW / uninterpreted HTTP POst information can be accessed with:
$GLOBALS['HTTP_RAW_POST_DATA']
This is useful in cases where the post Content-Type is not something PHP understands (such as text/xml).
04-Dec-2003 07:54
Running PHP 4.3 under IIS 5 on Windows XP, there is no $_SERVER['REQUEST_URI'] variable. This seems to fix it:
if(!isset($_SERVER['REQUEST_URI'])) {
$_SERVER['REQUEST_URI'] = substr($_SERVER['argv'][0], strpos($_SERVER['argv'][0], ';') + 1);
}
