- Spegnimento
- 9 agosto 2026 alle ore 17:46 UTC
- Autore
- kamo
- Impegno
- e7b7bc9
Un video che arriva in una conversazione non può essere giocato fino a quando la pagina è stata ricaricata, mentre un video che il membro aveva appena inviato ha sempre giocato. Entrambe le copie erano byte-identical — il re-sending dello stesso file ha prodotto un allegato di lavoro che indica allo stesso modo oggetto memorizzato — quindi non è mai stato il file o il formato. I tag multimediali sono emessi dal browser, così a differenza di ogni fetch nell'app che non possono portare l'intestazione per-tab X-***-Token e autenticare il *** cookie da solo. Verificato contro il proxy live: solo 206, solo intestazione 206, né 401. Che cosa? cookie viene ripiantato solo sull'attività dell'utente, quindi un membro seduto inattivo in una conversazione perde mentre il resto dell'app continua a lavorare da sessionStorage. Un video che arriva a destra allora ottiene un 401 sulla sua prima richiesta — e un <img> / <video> / elemento LATCHES quel fallimento. Non si asciuga mai, quindi il controllo rimane morto fino ad un reload costruisce un elemento fresco. L'invio è attività e mantiene vivo il cookie, che è il motivo per cui gli allegati di un membro non sono mai stati colpiti. Su errore l'elemento ora ri-pianta il cookie di sessione e ricarica la sua fonte una volta. Solo una volta: un secondo fallimento è reale, e riprovare in una sessione morta non aiuta nessuno. Questo è il recupero, non la prevenzione — media auth poggia ancora su un cookie che può trascurare mentre la sessione reale della scheda è viva.