diff --git a/src/Symfony/Component/HttpFoundation/Session/Storage/SessionStorageInterface.php b/src/Symfony/Component/HttpFoundation/Session/Storage/SessionStorageInterface.php
index 9f81847a10dd2..374b3fc7c4f79 100644
--- a/src/Symfony/Component/HttpFoundation/Session/Storage/SessionStorageInterface.php
+++ b/src/Symfony/Component/HttpFoundation/Session/Storage/SessionStorageInterface.php
@@ -76,10 +76,10 @@ public function setName($name);
      * Note regenerate+destroy should not clear the session data in memory
      * only delete the session data from persistent storage.
      *
-     * Care: When regenerating the session ID no locking is involved in PHPs
+     * Care: When regenerating the session ID no locking is involved in PHP's
      * session design. See https://bugs.php.net/bug.php?id=61470 for a discussion.
      * So you must make sure the regenerated session is saved BEFORE sending the
-     * headers with the new ID. Symfonys HttpKernel offers a listener for this.
+     * headers with the new ID. Symfony's HttpKernel offers a listener for this.
      * See Symfony\Component\HttpKernel\EventListener\SaveSessionListener.
      * Otherwise session data could get lost again for concurrent requests with the
      * new ID. One result could be that you get logged out after just logging in.
@@ -102,7 +102,7 @@ public function regenerate($destroy = false, $lifetime = null);
      * This method must invoke session_write_close() unless this interface is
      * used for a storage object design for unit or functional testing where
      * a real PHP session would interfere with testing, in which case it
-     * it should actually persist the session data if required.
+     * should actually persist the session data if required.
      *
      * @throws \RuntimeException If the session is saved without being started, or if the session
      *                           is already closed.