Gérer les interruptions de connexion

Lorsque PHP exécute un script, il se peut que l’utilisateur clique sur le bouton « Stop » de son navigateur. Dans ce cas, PHP stoppe l’execution du script immédiatement. La plupart du temps, cela ne pose aucun problème mais parfois il est important d’aller jusqu’au bout du script afin de garantir l’intégrité des données.

Pour cela, il suffit d’utiliser la fonction ignore_user_abort() qui indiquera à PHP de continuer l’exécution du script même en cas d’annulation de la part de l’utilisateur.

Mise à jour : Suite au commentaire d’Arnaud, je précise que si l’exécution du script se poursuit sur le serveur, du côté de l’utilisateur, l’affichage de la page est bien stoppé. Il peut donc aller sur une autre page alors même que le premier script n’a pas fini de s’exécuter sur le serveur.

Ce contenu a été publié dans PHP. Vous pouvez le mettre en favoris avec ce permalien.

6 réponses à Gérer les interruptions de connexion

  1. NiKo dit :

    Génialissime !

  2. Arnaud dit :

    A utiliser avec précaution cependant. Lorsqu’un utilisateur clique sur stop c’est peut etre parce que le site ne répond pas. Cette fonction peut vite poser des problèmes.

    Une autre fonction pour terminer des actions est register_shutdown_function.

  3. JMF dit :

    Arnaud> Je viens de faire des tests pour vérifier mes dires et je confirme.

    Lorsque l’utilisateur clique sur le bouton Stop, cela arrête le chargement de la page pour lui mais l’exécution du script sur le serveur va à son terme. Cela ne pose donc aucun problème à l’utilisateur qui ne s’en apercoit même pas.

    Si le serveur est en trop lent, cela sera géré par le max_execution_time.

    Quant à register_shutdown_function, elle n’a pas du tout le même usage. Je lui vois d’ailleurs très peu d’intérêt depuis que PHP supporte les destructeurs.

  4. Arnaud dit :

    JMF: c’est vrai que max-execution time permet d’éviter de se retrouver avec de nombreux scripts en train de se terminer (ou pire, de boucler sans fin).

    Les destructeurs sont supportés c’est vrai mais la fonction a d’autres intérets, pas uniquement celui d’émuler les destructeurs.

    D’un point de vue général il est mieux que l’application fonctionne sans nécessiter l’utilisation de ignore_user_abort 🙂

  5. cyruss dit :

    "Lorsque l’utilisateur clique sur le bouton Stop, cela arrête le chargement de la page pour lui mais l’exécution du script sur le serveur va à son terme. Cela ne pose donc aucun problème à l’utilisateur qui ne s’en apercoit même pas."

    Effectivement. Donc si tu cliques sur supprimer un article et que tu tentes rapidement de cliquer sur stop ca ne changera rien 🙂

    Cyruss

  6. JMF dit :

    cyruss> Tout à fait et c’est normal.

    L’utilisateur a cliqué sur un lien ou un bouton. Il a confirmé son souhait de supprimer l’article en validant un message d’alerte (Il faut toujours valider des opérations ayant des conséquences importantes pour éviter les erreurs de manupilation). S’il s’apercoit ensuite qu’il s’est trompé, c’est son problème. Il n’avait qu’est être plus vigilant.

    De plus, là où c’est très important que l’utilisateur n’arrête pas l’exécution du script quand ça lui chante, c’est quand une série d’actions doivent être accomplies en entier afin de garantir l’intégrité des données. Une sorte de transaction mais au niveau fonctionnel.

    Imaginons que pour valider un article, il faille modifier l’enregistrement dans la base de données, récupérer des informations dans un fichier, les écrire dans un autre puis supprimer le premier fichier. Le tout doit être atomique afin de préserver l’intégrité des données.

    Si l’on stoppe l’exécution du script au milieu de cela tu imagines la catastrophe ?

    Alors bien sûr, la plupart du temps ça n’a pas d’importance mais dans certains cas ça en a et là cette fonction peut rendre service.

Les commentaires sont fermés.