- Verschifft
- 9. August 2026 um 17:46 UTC
- Autor
- kamo
- Ausschuss
- e7b7bc9
Ein Video, das in einem Gespräch ankommt, konnte nicht abgespielt werden, bis die Seite neu geladen wurde, während ein Video, das das Mitglied gerade gesendet hatte, immer abgespielt. Beide Exemplare waren byte-identisch - Wiedereingabe der gleichen Datei erzeugte einen funktionierenden Anhang, der auf die gleiche zeigt gespeichertes Objekt - also war es nie die Datei oder das Format. Medien-Tags werden vom Browser ausgegeben, so dass im Gegensatz zu jedem holen in der App können sie nicht den X-***-Token-Header per-tab tragen und sich auf dem *** Cookie allein authentifiziert. Verifiziert gegen den Live-Proxy: Cookie-only 206, Header-only 206, weder 401. Das Cookie wird nur auf Benutzeraktivität neu gepflanzt, so dass ein Mitglied im Leerlauf in einem Gespräch sitzt verliert es, während der Rest der App weiter arbeitet von sessionStorage. Ein Video die rechts ankommt, bekommt dann auf die erste Anfrage einen 401 und einen <img>/<video>/<audio. Element LATCHES, dass Scheitern. Es retries nie, so bleibt die Kontrolle tot, bis ein Reload baut ein frisches Element. Senden ist Aktivität und hält das Cookie am Leben, die ist der Grund, warum die Eigensinne eines Mitglieds nie betroffen waren. Bei Fehler pflanzt das Element nun das Session-Cookie neu ein und lädt seine Quelle einmal neu. Einmal nur: Ein zweiter Ausfall ist real, und das Wiedererprobieren bei einer toten Sitzung hilft niemandem. Das ist Erholung, nicht Prävention - Medien ruhen immer noch auf einem Cookie, das ausgehen kann während die eigentliche Sitzung des Tabs lebendig ist.