Adding constants here and applied new structure

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@90186 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Gabor Hojtsy 2002-07-28 14:04:32 +00:00
parent cb34e8208e
commit 74c504d02e
2 changed files with 469 additions and 385 deletions

View file

@ -0,0 +1,42 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.1 $ -->
<section id="session.constants">
&reftitle.constants;
&extension.constants;
<variablelist>
<varlistentry>
<term>
<constant>SID</constant>
(<link linkend="language.types.integer">integer</link>)
</term>
<listitem>
<simpara>
Constant containing the session name and session ID in
the form of <literal>"name=ID"</literal>.
</simpara>
</listitem>
</varlistentry>
</variablelist>
</section>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->

View file

@ -1,85 +1,289 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.7 $ -->
<!-- $Revision: 1.8 $ -->
<reference id="ref.session">
<title>Session handling functions</title>
<titleabbrev>Sessions</titleabbrev>
<partintro>
<para>
Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more
customized applications and increase the appeal of your web site.
</para>
<para>
If you are familiar with the session management of PHPLIB, you
will notice that some concepts are similar to PHP's session
support.
</para>
<para>
A visitor accessing your web site is assigned an unique id, the
so-called session id. This is either stored in a cookie on the
user side or is propagated in the URL.
</para>
<para>
The session support allows you to register arbitrary numbers of
variables to be preserved across requests. When a visitor accesses
your site, PHP will check automatically (if session.auto_start is
set to 1) or on your request (explicitly through
<function>session_start</function> or implicitly through
<function>session_register</function>) whether a specific session
id has been sent with the request. If this is the case, the prior
saved environment is recreated.
</para>
<para>
All registered variables are serialized after the request
finishes. Registered variables which are undefined are marked as
being not defined. On subsequent accesses, these are not defined
by the session module unless the user defines them later.
</para>
<para>
The <link
linkend="ini.track-vars"><literal>track_vars</literal></link> and
<link
linkend="ini.register-globals"><literal>register_globals</literal></link>
configuration settings influence how the session variables get
stored and restored.
</para>
<note>
<section id="session.intro">
&reftitle.intro;
<para>
As of PHP 4.0.3, <link
Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more
customized applications and increase the appeal of your web site.
</para>
<para>
If you are familiar with the session management of PHPLIB, you
will notice that some concepts are similar to PHP's session
support.
</para>
<para>
A visitor accessing your web site is assigned an unique id, the
so-called session id. This is either stored in a cookie on the
user side or is propagated in the URL.
</para>
<para>
The session support allows you to register arbitrary numbers of
variables to be preserved across requests. When a visitor accesses
your site, PHP will check automatically (if session.auto_start is
set to 1) or on your request (explicitly through
<function>session_start</function> or implicitly through
<function>session_register</function>) whether a specific session
id has been sent with the request. If this is the case, the prior
saved environment is recreated.
</para>
<para>
All registered variables are serialized after the request
finishes. Registered variables which are undefined are marked as
being not defined. On subsequent accesses, these are not defined
by the session module unless the user defines them later.
</para>
<note>
<para>
Session handling was added in PHP 4.0.
</para>
</note>
</section>
<section id="session.requirements">
&reftitle.required;
&no.requirement;
</section>
<section id="session.installation">
&reftitle.install;
<para>
Session support is enabled in PHP by default. If you would
not like to build your PHP with session support, you should
specify the <option role="configure">--disable-session</option>
option to configure.
</para>
</section>
<section id="session.configuration">
&reftitle.runtime;
<para>
The session management system supports a number of configuration
options which you can place in your &php.ini; file. We will give a
short overview.
<itemizedlist>
<listitem>
<simpara>
<literal>session.save_handler</literal> defines the name of the
handler which is used for storing and retrieving data
associated with a session. Defaults to
<literal>files</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.save_path</literal> defines the argument which
is passed to the save handler. If you choose the default files
handler, this is the path where the files are created.
Defaults to <literal>/tmp</literal>. If
<literal>session.save_path</literal>'s path depth is more than
2, garbage collection will not be performed.
</simpara>
<warning>
<para>
If you leave this set to a world-readable directory, such as
<filename>/tmp</filename> (the default), other users on the
server may be able to hijack sessions by getting the list of
files in that directory.
</para>
</warning>
</listitem>
<listitem>
<simpara>
<literal>session.name</literal> specifies the name of the
session which is used as cookie name. It should only contain
alphanumeric characters. Defaults to
<literal>PHPSESSID</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.auto_start</literal> specifies whether the
session module starts a session automatically on request
startup. Defaults to <literal>0</literal> (disabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_lifetime</literal> specifies the lifetime of
the cookie in seconds which is sent to the browser. The value 0
means "until the browser is closed." Defaults to
<literal>0</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.serialize_handler</literal> defines the name
of the handler which is used to serialize/deserialize
data. Currently, a PHP internal format (name
<literal>php</literal>) and WDDX is supported (name
<literal>wddx</literal>). WDDX is only available, if PHP is
compiled with <link linkend="ref.wddx">WDDX
support</link>. Defaults to <literal>php</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.gc_probability</literal> specifies the
probability that the gc (garbage collection) routine is started
on each request in percent. Defaults to <literal>1</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.gc_maxlifetime</literal> specifies the number
of seconds after which data will be seen as 'garbage' and
cleaned up.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.referer_check</literal> contains the substring you
want to check each HTTP Referer for. If the Referer was sent by the
client and the substring was not found, the embedded session id will
be marked as invalid. Defaults to the empty string.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.entropy_file</literal> gives a path to an
external resource (file) which will be used as an additional
entropy source in the session id creation process. Examples are
<literal>/dev/random</literal> or
<literal>/dev/urandom</literal> which are available on many
Unix systems.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.entropy_length</literal> specifies the number
of bytes which will be read from the file specified
above. Defaults to <literal>0</literal> (disabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_cookies</literal> specifies whether the
module will use cookies to store the session id on the client
side. Defaults to <literal>1</literal> (enabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_only_cookies</literal> specifies whether the
module will <emphasis role="strong">only</emphasis> use cookies to
store the session id on the client side. Defaults to
<literal>0</literal> (disabled, for backward compatibility). Enabling
this setting prevents attacks involved passing session ids in URLs.
This setting was added in <literal>PHP</literal> 4.3.0.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_path</literal> specifies path to set
in session_cookie. Defaults to <literal>/</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_domain</literal> specifies domain to
set in session_cookie. Default is none at all.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cache_limiter</literal> specifies cache
control method to use for session pages
(none/nocache/private/private_no_expire/public). Defaults to
<literal>nocache</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cache_expire</literal> specifies time-to-live
for cached session pages in minutes, this has no effect for
nocache limiter. Defaults to <literal>180</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_trans_sid</literal> whether transparent sid support
is enabled or not if enabled by compiling with
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link>.
Defaults to <literal>1</literal> (enabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>url_rewriter.tags</literal> spefifies which html tags are
rewritten to include session id if transparent sid support is enabled.
Defaults to <literal>a=href,area=href,frame=src,input=src,form=fakeentry</literal>
</simpara>
</listitem>
</itemizedlist>
</para>
<para>
The <link
linkend="ini.track-vars"><literal>track_vars</literal></link> and
<link
linkend="ini.register-globals"><literal>register_globals</literal></link>
configuration settings influence how the session variables get
stored and restored.
</para>
<note>
<para>
As of PHP 4.0.3, <link
linkend="ini.track-vars"><literal>track_vars</literal></link> is
always turned on.
</para>
</note>
</section>
<section id="session.resources">
&reftitle.resources;
&no.resource;
</section>
&reference.session.constants;
<section id="session.examples">
&reftitle.examples;
<note>
<para>
As of PHP 4.1.0, <varname>$_SESSION</varname> is available as
global variable just like <varname>$_POST</varname>,
<varname>$_GET</varname>, <varname>$_REQUEST</varname> and so on.
Not like <varname>$HTTP_SESSION_VARS</varname>,
<varname>$_SESSION</varname> is always global. Therefore,
<literal>global</literal> should not be used for
<varname>$_SESSION</varname>.
</para>
</note>
<para>
If <link
linkend="ini.track-vars"><literal>track_vars</literal></link> is
always turned on.
</para>
</note>
<note>
<para>
As of PHP 4.1.0, <varname>$_SESSION</varname> is available as
global variable just like <varname>$_POST</varname>,
<varname>$_GET</varname>, <varname>$_REQUEST</varname> and so on.
Not like <varname>$HTTP_SESSION_VARS</varname>,
<varname>$_SESSION</varname> is always global. Therefore,
<literal>global</literal> should not be used for
<varname>$_SESSION</varname>.
</para>
</note>
<para>
If <link
linkend="ini.track-vars"><literal>track_vars</literal></link> is
enabled and <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is disabled, only members of the global associative array
<varname>$HTTP_SESSION_VARS</varname> can be registered as session
variables. The restored session variables will only be available
in the array <varname>$HTTP_SESSION_VARS</varname>.
<example>
<title>
Registering a variable with <link
linkend="ini.track-vars"><literal>track_vars</literal></link>
enabled
</title>
<programlisting role="php">
enabled and <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is disabled, only members of the global associative array
<varname>$HTTP_SESSION_VARS</varname> can be registered as session
variables. The restored session variables will only be available
in the array <varname>$HTTP_SESSION_VARS</varname>.
<example>
<title>
Registering a variable with <link
linkend="ini.track-vars"><literal>track_vars</literal></link>
enabled
</title>
<programlisting role="php">
<![CDATA[
<?php
session_start();
@ -91,23 +295,23 @@ else {
}
?>
]]>
</programlisting>
</example>
</para>
<para>
Use of <varname>$_SESSION</varname> (or
<varname>$HTTP_SESSION_VARS</varname> with PHP 4.0.6 or less) is
recommended for security and code readablity. With
<varname>$_SESSION</varname> or
<varname>$HTTP_SESSION_VARS</varname>, there is no need to use
session_register()/session_unregister()/session_is_registered()
functions. Users can access session variable like a normal
variable.
<example>
<title>
Registering a variable with $_SESSION.
</title>
<programlisting role="php">
</programlisting>
</example>
</para>
<para>
Use of <varname>$_SESSION</varname> (or
<varname>$HTTP_SESSION_VARS</varname> with PHP 4.0.6 or less) is
recommended for security and code readablity. With
<varname>$_SESSION</varname> or
<varname>$HTTP_SESSION_VARS</varname>, there is no need to use
session_register()/session_unregister()/session_is_registered()
functions. Users can access session variable like a normal
variable.
<example>
<title>
Registering a variable with $_SESSION.
</title>
<programlisting role="php">
<![CDATA[
<?php
session_start();
@ -119,13 +323,13 @@ if (!isset($_SESSION['count'])) {
}
?>
]]>
</programlisting>
</example>
<example>
<title>
Unregistering a variable with $_SESSION.
</title>
<programlisting role="php">
</programlisting>
</example>
<example>
<title>
Unregistering a variable with $_SESSION.
</title>
<programlisting role="php">
<![CDATA[
<?php
session_start();
@ -133,46 +337,46 @@ session_start();
unset($_SESSION['count']);
?>
]]>
</programlisting>
</example>
</para>
<para>
If <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is enabled, then all global variables can be registered as session
variables and the session variables will be restored to
corresponding global variables. Since PHP must know which global
variables are registered as session variables, users must register
variables with session_register() function while
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
does not need to use session_register().
<caution>
<para>
If you are using
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
and disable <link
linkend="ini.register-globals"><literal>register_globals</literal></link>,
do not use <function>session_register</function>,
<function>session_is_registered</function> and
<function>session_unregister</function>.
</para>
<para>
If you enable <link
</programlisting>
</example>
</para>
<para>
If <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is enabled, then all global variables can be registered as session
variables and the session variables will be restored to
corresponding global variables. Since PHP must know which global
variables are registered as session variables, users must register
variables with session_register() function while
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
does not need to use session_register().
<caution>
<para>
If you are using
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
and disable <link
linkend="ini.register-globals"><literal>register_globals</literal></link>,
<function>session_unregister</function> should be used since
session variables are registered as global variables when
session data is deserialized. Disabling <link
do not use <function>session_register</function>,
<function>session_is_registered</function> and
<function>session_unregister</function>.
</para>
<para>
If you enable <link
linkend="ini.register-globals"><literal>register_globals</literal></link>,
<function>session_unregister</function> should be used since
session variables are registered as global variables when
session data is deserialized. Disabling <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is recommended for both security and performance reason.
</para>
</caution>
<example>
<title>
Registering a variable with <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
is recommended for both security and performance reason.
</para>
</caution>
<example>
<title>
Registering a variable with <link
linkend="ini.register-globals"><literal>register_globals</literal></link>
enabled
</title>
<programlisting role="php">
enabled
</title>
<programlisting role="php">
<![CDATA[
<?php
if (!session_is_registered('count')) {
@ -184,69 +388,73 @@ else {
}
?>
]]>
</programlisting>
</example>
</para>
<para>
If both <link
linkend="ini.track-vars"><literal>track_vars</literal></link> and
<link
linkend="ini.register-globals"><literal>register_globals</literal></link>
are enabled, then the globals variables and the
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
entries will reference the same value for already registered
variables.
</para>
<para>
If user use session_register() to register session variable,
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
will not have these variable in array until it is loaded from
session storage. (i.e. until next request)
</para>
<para>
There are two methods to propagate a session id:
<itemizedlist>
<listitem>
<simpara>
Cookies
</simpara>
</listitem>
<listitem>
<simpara>
URL parameter
</simpara>
</listitem>
</itemizedlist>
</para>
<para>
The session module supports both methods. Cookies are optimal, but
since they are not reliable (clients are not bound to accept
them), we cannot rely on them. The second method embeds the
session id directly into URLs.
</para>
<para>
PHP is capable of doing this transparently when compiled with
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link>. If you enable this option,
relative URIs will be changed to contain the session id
automatically. Alternatively, you can use the constant
<literal>SID</literal> which is defined, if the client did not
send the appropriate cookie. <literal>SID</literal> is either of
the form <literal>session_name=session_id</literal> or is an empty
string.
<note>
<para>
The <link linkend="ini.arg_separator.output">arg_separator.output</link>
&php.ini; directive allows to customize the argument seperator.
</para>
</note>
</para>
<para>
The following example demonstrates how to register a variable, and
how to link correctly to another page using SID.
<example>
<title>Counting the number of hits of a single user</title>
<programlisting role="php">
</programlisting>
</example>
</para>
<para>
If both <link
linkend="ini.track-vars"><literal>track_vars</literal></link> and
<link
linkend="ini.register-globals"><literal>register_globals</literal></link>
are enabled, then the globals variables and the
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
entries will reference the same value for already registered
variables.
</para>
<para>
If user use session_register() to register session variable,
<varname>$HTTP_SESSION_VARS</varname>/<varname>$_SESSION</varname>
will not have these variable in array until it is loaded from
session storage. (i.e. until next request)
</para>
</section>
<section id="session.idpassing">
<title>Passing the Session ID</title>
<para>
There are two methods to propagate a session id:
<itemizedlist>
<listitem>
<simpara>
Cookies
</simpara>
</listitem>
<listitem>
<simpara>
URL parameter
</simpara>
</listitem>
</itemizedlist>
</para>
<para>
The session module supports both methods. Cookies are optimal, but
since they are not reliable (clients are not bound to accept
them), we cannot rely on them. The second method embeds the
session id directly into URLs.
</para>
<para>
PHP is capable of doing this transparently when compiled with
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link>. If you enable this option,
relative URIs will be changed to contain the session id
automatically. Alternatively, you can use the constant
<literal>SID</literal> which is defined, if the client did not
send the appropriate cookie. <literal>SID</literal> is either of
the form <literal>session_name=session_id</literal> or is an empty
string.
<note>
<para>
The <link linkend="ini.arg_separator.output">arg_separator.output</link>
&php.ini; directive allows to customize the argument seperator.
</para>
</note>
</para>
<para>
The following example demonstrates how to register a variable, and
how to link correctly to another page using SID.
<example>
<title>Counting the number of hits of a single user</title>
<programlisting role="php">
<![CDATA[
<?php
if (!session_is_registered('count')) {
@ -268,197 +476,31 @@ Hello visitor, you have seen this page <?php echo $count; ?> times.<p>;
To continue, <A HREF="nextpage.php?<?php echo SID?>">click here</A>
]]>
</programlisting>
</example>
</para>
<para>
The <literal>&lt;?=SID?&gt;</literal> is not necessary, if
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link> was used to compile PHP.
</para>
<note>
<para>
Non-relative URLs are assumed to point to external sites and
hence don't append the SID, as it would be a security risk to
leak the SID to a different server.
</programlisting>
</example>
</para>
<para>
The <literal>&lt;?=SID?&gt;</literal> is not necessary, if
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link> was used to compile PHP.
</para>
</note>
<para>
To implement database storage, or any other storage method, you
will need to use <function>session_set_save_handler</function> to
create a set of user-level storage functions.
</para>
<para>
The session management system supports a number of configuration
options which you can place in your &php.ini; file. We will give a
short overview.
<itemizedlist>
<listitem>
<simpara>
<literal>session.save_handler</literal> defines the name of the
handler which is used for storing and retrieving data
associated with a session. Defaults to
<literal>files</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.save_path</literal> defines the argument which
is passed to the save handler. If you choose the default files
handler, this is the path where the files are created.
Defaults to <literal>/tmp</literal>. If
<literal>session.save_path</literal>'s path depth is more than
2, garbage collection will not be performed.
</simpara>
<warning>
<para>
If you leave this set to a world-readable directory, such as
<filename>/tmp</filename> (the default), other users on the
server may be able to hijack sessions by getting the list of
files in that directory.
</para>
</warning>
</listitem>
<listitem>
<simpara>
<literal>session.name</literal> specifies the name of the
session which is used as cookie name. It should only contain
alphanumeric characters. Defaults to
<literal>PHPSESSID</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.auto_start</literal> specifies whether the
session module starts a session automatically on request
startup. Defaults to <literal>0</literal> (disabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_lifetime</literal> specifies the lifetime of
the cookie in seconds which is sent to the browser. The value 0
means "until the browser is closed." Defaults to
<literal>0</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.serialize_handler</literal> defines the name
of the handler which is used to serialize/deserialize
data. Currently, a PHP internal format (name
<literal>php</literal>) and WDDX is supported (name
<literal>wddx</literal>). WDDX is only available, if PHP is
compiled with <link linkend="ref.wddx">WDDX
support</link>. Defaults to <literal>php</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.gc_probability</literal> specifies the
probability that the gc (garbage collection) routine is started
on each request in percent. Defaults to <literal>1</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.gc_maxlifetime</literal> specifies the number
of seconds after which data will be seen as 'garbage' and
cleaned up.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.referer_check</literal> contains the substring you
want to check each HTTP Referer for. If the Referer was sent by the
client and the substring was not found, the embedded session id will
be marked as invalid. Defaults to the empty string.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.entropy_file</literal> gives a path to an
external resource (file) which will be used as an additional
entropy source in the session id creation process. Examples are
<literal>/dev/random</literal> or
<literal>/dev/urandom</literal> which are available on many
Unix systems.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.entropy_length</literal> specifies the number
of bytes which will be read from the file specified
above. Defaults to <literal>0</literal> (disabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_cookies</literal> specifies whether the
module will use cookies to store the session id on the client
side. Defaults to <literal>1</literal> (enabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_only_cookies</literal> specifies whether the
module will <emphasis role="strong">only</emphasis> use cookies to
store the session id on the client side. Defaults to
<literal>0</literal> (disabled, for backward compatibility). Enabling
this setting prevents attacks involved passing session ids in URLs.
This setting was added in <literal>PHP</literal> 4.3.0.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_path</literal> specifies path to set
in session_cookie. Defaults to <literal>/</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cookie_domain</literal> specifies domain to
set in session_cookie. Default is none at all.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cache_limiter</literal> specifies cache
control method to use for session pages
(none/nocache/private/private_no_expire/public). Defaults to
<literal>nocache</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.cache_expire</literal> specifies time-to-live
for cached session pages in minutes, this has no effect for
nocache limiter. Defaults to <literal>180</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>session.use_trans_sid</literal> whether transparent sid support
is enabled or not if enabled by compiling with
<link linkend="install.configure.enable-trans-sid">
<literal>--enable-trans-sid</literal></link>.
Defaults to <literal>1</literal> (enabled).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>url_rewriter.tags</literal> spefifies which html tags are
rewritten to include session id if transparent sid support is enabled.
Defaults to <literal>a=href,area=href,frame=src,input=src,form=fakeentry</literal>
</simpara>
</listitem>
</itemizedlist>
<note>
<para>
Session handling was added in PHP 4.0.
Non-relative URLs are assumed to point to external sites and
hence don't append the SID, as it would be a security risk to
leak the SID to a different server.
</para>
</note>
</para>
</section>
<section id="session.customhandler">
<title>Custom Session Handlers</title>
<para>
To implement database storage, or any other storage method, you
will need to use <function>session_set_save_handler</function> to
create a set of user-level storage functions.
</para>
</section>
</partintro>
&reference.session.functions;