Récupérer une session de navigateur après une interruption réseau
Utilisez des reprises bornées, des points de contrôle et des limites de confidentialité pour éviter les effets en double.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Une interruption réseau ne prouve pas qu'une action est terminée. La connexion peut échouer avant la requête, après son acceptation par le serveur ou pendant l'attente de la réponse. Conservez l'affectation de session, marquez un point de contrôle et ne répétez qu'une opération dont la fin est vérifiable.
TL;DR
- Identifiez le canal interrompu avant toute reprise.
- Conservez le même profil, stockage et itinéraire pendant une génération de reprise.
- Réessayez les lectures avec un budget borné et vérifiez les écritures avant de les répéter.
- Séparez les preuves de nettoyage du navigateur, de révocation serveur et de suppression de l'hôte.
- BotBrowser rejoue un point autorisé, mais ne confirme pas un effet distant sans accusé.
Sommaire
- Fixer le contrat de session
- Points de contrôle et décision
- Reprise avec un budget borné
- Confidentialité et vérification
- Capacité et limite de BotBrowser
- Conclusion
- FAQ
Fixer le contrat de session
Avant la première page, consignez la référence du travail, le profile approuvé, le propriétaire du stockage, la version du navigateur, la route et la génération du lease. Excluez mots de passe, corps de pages et URL inutiles. Les messages d'une ancienne génération doivent être rejetés après réparation.
Séparez l'intention durable de l'état volatile. L'intention contient l'action, le dernier point accepté, le budget et le nettoyage. Pages ouvertes, mémoire, websockets et requêtes en vol sont volatils.
Points de contrôle et décision
Un point de contrôle est une frontière d'acceptation définie par l'application : réponse validée, document enregistré ou accusé documenté. Une navigation réussie ne prouve pas un effet de bord.
| Observation | Première action | Règle | Résultat attendu |
|---|---|---|---|
| Lecture sans réponse | Reconnecter puis relire | Reprise bornée et temporisée | Lecture validée ou échec classé |
| Écriture sans accusé | Interroger l'état | Répéter avec clé idempotente seulement | Une issue enregistrée |
| Contrôle perdu | Suspendre l'admission | Ne pas rejouer aveuglément | Un propriétaire reprend ou isole |
| Route indisponible | Garder l'affectation en pause | Ne pas changer de route arbitraire | Échec récupérable visible |
Sans consultation d'état ou idempotence fournie par l'application, arrêtez-vous au point de contrôle et demandez une réconciliation.
Reprise avec un budget borné
Classez la panne (requête, websocket, proxy, contrôle), fixez un nombre et un âge maximum avec temporisation variable, puis restez dans la route déclarée. Changer de route peut changer l'identité réseau et exige un nouveau lease selon la politique.
Quand le budget est épuisé, marquez l'échec récupérable, conservez le dernier point accepté, drainez le context et isolez le stockage incertain. Consignez génération, version et catégorie sans jetons ni URL privées.
Confidentialité et vérification
Cookies, stockage, IndexedDB, cache, téléchargements et sessions serveur ont des cycles distincts. MDN Clear-Site-Data décrit le nettoyage par origin, pas la suppression distante. Les principes de confidentialité du W3C soutiennent minimisation et limitation de finalité.
Comparez affectation, route, ordre des points, accusé et nettoyage dans une preuve structurée. Vérifiez avec un context autorisé neuf; marquez toute révocation distante asynchrone comme en attente.
Capacité et limite de BotBrowser
BotBrowser peut rejouer un point de contrôle autorisé dans un profile, une version, une route et un context déclarés et comparer les résultats visibles après une interruption contrôlée. Il ne peut pas déterminer l'acceptation d'une écriture sans accusé, révoquer des sessions, inspecter tous les artefacts de l'hôte ni garantir la continuité. Le propriétaire de l'application reste responsable de l'idempotence, de l'autorisation et de la conservation.
À lire : Résilience des contextes longue durée et Cohérence de la couche réseau.
Conclusion
Récupérez l'intention, pas la connexion perdue : figez la propriété, vérifiez la dernière frontière, réconciliez les écritures inconnues et bornez les reprises. Lancez ensuite un fixture autorisé avec une interruption injectée et vérifiez résultat et nettoyage.
Un journal de reprise utile conserve un identifiant stable, la version du point de contrôle, le numéro d'essai, la classe de route et un résultat court comme confirmé, inconnu ou isolé. Il ne doit pas devenir une copie de l'historique de navigation : excluez secrets, corps de requêtes, URL complètes et captures.
Chaque point doit nommer l'autorité qui répond à la question suivante : accusé applicatif, recherche par clé d'idempotence, état de transaction ou décision d'un responsable. Sans cette autorité, conservez l'incertitude et arrêtez le lease au lieu d'inventer une nouvelle écriture.
Les preuves du navigateur et celles du service sont différentes. La première montre une requête envoyée, une réponse lue ou un context fermé ; la seconde montre une transaction validée, dédupliquée ou révoquée. Une assertion verte du navigateur ne prouve pas un commit distant.
Pour un téléchargement interrompu, comparez la taille ou le condensat lorsqu'il existe, isolez les fichiers ambigus et rendez le nettoyage visible. Pour un websocket interrompu, comparez la révision et ne rejouez que les opérations déclarées sûres par le serveur.
Un changement de route mérite son propre point : il peut modifier localisation, politique ou autorisation. Fermez l'ancien lease, notez la raison et vérifiez la politique avant de continuer.
L'acceptation finale peut être un tableau court : propriétaire, point, accusé serveur, nettoyage navigateur et conservation. Marquez chaque ligne observée, en attente ou sans objet. Collectez seulement les signaux nécessaires et évitez de réunir fingerprint, proxy et session en une identité durable.
FAQ
Faut-il reprendre chaque délai dépassé ?
Non. Reprenez une lecture ou une opération explicitement idempotente; consultez l'état avant une nouvelle écriture.
Un nouveau context conserve-t-il la session ?
Seulement si la politique autorise le même profile et un stockage intègre. Il ne restaure pas la mémoire volatile.
Le nettoyage navigateur révoque-t-il la session serveur ?
Non. Ce sont deux frontières avec deux preuves.
Que vérifie BotBrowser ?
Il rejoue le point autorisé et compare les résultats visibles; il ne certifie ni effet distant ni effacement de l'hôte.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.