Skip to content

Commit 561b404

Browse files
committed
Merge branch '5.4' into 6.2
* 5.4: fix link to psr7 bridge classes [Process] 📝 process: `create_new_console` is only for windows Adding section "Configuring Garbage Collection"
2 parents e39cbf6 + 56f05a8 commit 561b404

File tree

3 files changed

+49
-6
lines changed

3 files changed

+49
-6
lines changed

components/process.rst

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -109,6 +109,11 @@ You can configure the options passed to the ``other_options`` argument of
109109
// this option allows a subprocess to continue running after the main script exited
110110
$process->setOptions(['create_new_console' => true]);
111111

112+
.. note::
113+
114+
The ``create_new_console`` option is only available on Windows!
115+
116+
112117
Using Features From the OS Shell
113118
--------------------------------
114119

components/psr7.rst

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -29,9 +29,9 @@ Usage
2929
Converting from HttpFoundation Objects to PSR-7
3030
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3131

32-
The bridge provides an interface of a factory called
33-
:class:`Symfony\\Bridge\\PsrHttpMessage\\HttpMessageFactoryInterface`
34-
that builds objects implementing PSR-7 interfaces from HttpFoundation objects.
32+
The bridge provides an interface of a factory called
33+
`HttpMessageFactoryInterface`_ that builds objects implementing PSR-7
34+
interfaces from HttpFoundation objects.
3535

3636
The following code snippet explains how to convert a :class:`Symfony\\Component\\HttpFoundation\\Request`
3737
to a ``Nyholm\Psr7\ServerRequest`` class implementing the
@@ -66,8 +66,8 @@ Converting Objects implementing PSR-7 Interfaces to HttpFoundation
6666
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6767

6868
On the other hand, the bridge provide a factory interface called
69-
:class:`Symfony\\Bridge\\PsrHttpMessage\\HttpFoundationFactoryInterface`
70-
that builds HttpFoundation objects from objects implementing PSR-7 interfaces.
69+
`HttpFoundationFactoryInterface`_ that builds HttpFoundation objects from
70+
objects implementing PSR-7 interfaces.
7171

7272
The next snippet explain how to convert an object implementing the
7373
``Psr\Http\Message\ServerRequestInterface`` interface to a
@@ -93,3 +93,5 @@ to a :class:`Symfony\\Component\\HttpFoundation\\Response` instance::
9393
.. _`PSR-7`: https://www.php-fig.org/psr/psr-7/
9494
.. _`PSR-17`: https://www.php-fig.org/psr/psr-17/
9595
.. _`libraries that implement psr/http-factory-implementation`: https://packagist.org/providers/psr/http-factory-implementation
96+
.. _`HttpMessageFactoryInterface`: https://github.com/symfony/psr-http-message-bridge/blob/main/HttpMessageFactoryInterface.php
97+
.. _`HttpFoundationFactoryInterface`: https://github.com/symfony/psr-http-message-bridge/blob/main/HttpFoundationFactoryInterface.php

session.rst

Lines changed: 37 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -409,7 +409,7 @@ logged in by destroying the session after a certain period of idle time. For
409409
example, it is common for banking applications to log the user out after just
410410
5 to 10 minutes of inactivity. Setting the cookie lifetime here is not
411411
appropriate because that can be manipulated by the client, so we must do the expiry
412-
on the server side. The easiest way is to implement this via garbage collection
412+
on the server side. The easiest way is to implement this via :ref:`session garbage collection <session-garbage-collection>`
413413
which runs reasonably frequently. The ``cookie_lifetime`` would be set to a
414414
relatively high value, and the garbage collection ``gc_maxlifetime`` would be set
415415
to destroy sessions at whatever the desired idle period is.
@@ -443,6 +443,42 @@ particular cookie by reading the ``getLifetime()`` method::
443443
The expiry time of the cookie can be determined by adding the created
444444
timestamp and the lifetime.
445445

446+
.. _session-garbage-collection:
447+
448+
Configuring Garbage Collection
449+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
450+
451+
When a session opens, PHP will call the ``gc`` handler randomly according to the
452+
probability set by ``session.gc_probability`` / ``session.gc_divisor``. For
453+
example if these were set to ``5/100`` respectively, it would mean a probability
454+
of 5%. Similarly, ``3/4`` would mean a 3 in 4 chance of being called, i.e. 75%.
455+
456+
If the garbage collection handler is invoked, PHP will pass the value stored in
457+
the ``php.ini`` directive ``session.gc_maxlifetime``. The meaning in this context is
458+
that any stored session that was saved more than ``gc_maxlifetime`` ago should be
459+
deleted. This allows one to expire records based on idle time.
460+
461+
However, some operating systems (e.g. Debian) do their own session handling and set
462+
the ``session.gc_probability`` variable to ``0`` to stop PHP doing garbage
463+
collection. That's why Symfony now overwrites this value to ``1``.
464+
465+
If you wish to use the original value set in your ``php.ini``, add the following
466+
configuration:
467+
468+
.. code-block:: yaml
469+
470+
# config/packages/framework.yaml
471+
framework:
472+
session:
473+
# ...
474+
gc_probability: null
475+
476+
You can configure these settings by passing ``gc_probability``, ``gc_divisor``
477+
and ``gc_maxlifetime`` in an array to the constructor of
478+
:class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\NativeSessionStorage`
479+
or to the :method:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\NativeSessionStorage::setOptions`
480+
method.
481+
446482
.. _session-database:
447483

448484
Store Sessions in a Database

0 commit comments

Comments
 (0)