Multipath TCP (MPTCP) pour DiscourseHub et PWA iOS Safari derrière Caddy

Assistance produit Installation
, , , ,
2

Suite : édition de publication iOS interrompue et continuité de la connexion HTTP/3

J’ai maintenant rencontré un exemple concret du problème de continuité de connexion dont je parlais.

Le 21 octobre 2026, alors que j’étais en train d’éditer une publication sur mon instance Discourse privée via l’iPad PWA Safari sur un iPhone 16 Pro, la barre bleue Enregistrement est restée bloquée. Je venais juste de dicté quelques notes de cours supplémentaires.

L’éditeur n’était plus accessible, y compris lorsque je touchais la barre bleue Enregistrement, ce qui m’a empêché de copier le texte non enregistré ailleurs.

Après avoir attendu plus longtemps que d’habitude, j’ai manuellement désactivé le Wi-Fi pour essayer la connectivité cellulaire. La page n’a pas immédiatement changé, mais les tentatives suivantes de navigation semblaient également se figer.

J’ai ensuite examiné les journaux Caddy et nginx ainsi que l’historique des révisions de la publication.

À 12:20:08 BST :

  • Caddy a enregistré une requête PUT /posts/70695 HTTP/3 provenant de la connexion Wi-Fi universitaire, avec tous les 1 000 octets du corps de la requête reçus, mais un statut 0.

  • nginx a enregistré la requête correspondante comme HTTP 400, sans temps de traitement de route Discourse ou d’amont.

  • Deux autres requêtes iPhone provenant de la connexion cellulaire ont également reçu un HTTP 400 à la même seconde.

  • Aucune révision de publication réussie n’a été enregistrée à ce moment-là.

Une édition ultérieure a réussi à 12:20:55 BST, mais le texte dicté manquait.

Il y a aussi eu une sauvegarde automatique réussie du brouillon Discourse à 12:19:44 BST, bien que je ne puisse pas établir si elle contenait le texte manquant.

Je reconnais que la désactivation manuelle du Wi-Fi a pu interrompre les requêtes en attente. Cependant, l’opération d’enregistrement initiale était déjà bloquée avant que je change de connexion réseau.

Cela soulève deux questions liées à ma publication originale :

  1. Migration de connexion QUIC : Existe-t-il une méthode recommandée pour déterminer si le navigateur iOS a tenté la migration de la connexion HTTP/3 existante, plutôt que d’établir une nouvelle connexion ou d’abandonner les requêtes en attente ?

  2. Récupération de l’éditeur Discourse : Si une requête d’édition de publication se bloque ou est interrompue, l’éditeur est-il censé rester inaccessible derrière l’état d’enregistrement ? Existe-t-il un mécanisme de délai d’attente, de nouvelle tentative ou de récupération qui devrait préserver le texte non enregistré ?

Je suis particulièrement intéressé par la deuxième question car je n’ai pas pu revenir à l’éditeur pour copier mon travail avant de tenter de rétablir la connectivité.

Je n’ai modifié aucun paramètre Caddy, nginx ou HTTP/3 à la suite de cet incident, car les preuves disponibles n’identifient pas encore ce qui a causé l’immobilisation initiale de l’opération d’enregistrement.