- Expédié
- 9 août 2026 à 17:46 UTC
- Auteur
- kamo
- Commite
- e7b7bc9
Une vidéo arrivant dans une conversation ne pouvait pas être jouée jusqu'à ce que la page soit rechargée. alors qu'une vidéo que le membre venait d'envoyer toujours jouée. Les deux copies étaient identiques à l'octet - la réexpédition du même fichier a produit une pièce jointe de travail pointant de la même manière. objet stocké - de sorte qu'il n'a jamais été le fichier ou le format. Les balises multimédias sont émises par le navigateur, donc contrairement à chaque recherche dans l'application, elles ne peuvent pas porter l'en-tête per-z-token et authentifier seul sur le z cookie. Vérifié contre le proxy vivant: cookie-uniquement 206, en-tête seulement 206, ni 401. Que cookie n'est replanté que sur l'activité de l'utilisateur, donc un membre assis inactif dans une conversation le perd tandis que le reste de l'application se poursuit en travaillant à partir de sessionStorage. Une vidéo qui arrive juste puis obtient un 401 sur sa première demande - et un "img"/vidéo/-audio- Élément LATCHE ce défaut. Il ne se réarrange jamais, donc le contrôle reste mort jusqu'à ce qu'un le rechargement construit un nouvel élément. L'envoi est une activité et maintient le biscuit vivant, qui C'est pourquoi les attachements d'un membre n'ont jamais été affectés. En cas d'erreur, l'élément replante maintenant le cookie de session et recharge sa source une fois. Une seule fois : un deuxième échec est réel, et se réessayer à une session morte n'aide personne. C'est la récupération, pas la prévention et l'auth auth des médias repose toujours sur un cookie qui peut s'éteindre alors que la vraie session de l'onglet est vivante.