Che cosa significa ERR_BLOCKED_BY_CLIENT e perché il tuo server non l'ha mai visto

La lista degli errori di rete di Chromium stesso lo descrive in una sola frase:

Il client ha scelto di bloccare la richiesta.

La parola che porta il peso è scelto. Niente è fallito. Nessun server era giù, nessun nome è rimasto irrisolto, nessun certificato era sbagliato. Qualcosa che stava girando sulla macchina stessa del visitatore ha guardato una richiesta che la tua pagina stava per fare e ha deciso che non sarebbe stata fatta.

Il che significa che il tuo server non l’ha mai vista. Non c’è nessuna riga nel tuo access log, nessuna voce nel tuo error tracker, e niente da trovare dalla tua parte affatto, perché dal punto di vista della tua infrastruttura la richiesta non esiste.

Chi è il client

Di solito un’estensione. I blocker di annunci e di tracker sono il caso comune, e sono molto più ampiamente installati di quanto la maggior parte dei team assuma quando guardano alle loro proprie macchine.

Ma la categoria è più ampia di così. Il software di sicurezza aziendale filtra le richieste prima che lascino la macchina. Alcuni prodotti antivirus fanno lo stesso. Una configurazione di proxy aziendale può rifiutare un host. Le impostazioni del browser su un dispositivo gestito possono bloccare una categoria completamente. Tutti questi producono lo stesso errore, e nessuno di loro è qualcosa che la persona che segnala il problema sa di avere.

L’unica cosa che condividono è che stanno fra il tuo codice e la rete, all’interno dell’ambiente dell’utente, dove non hai visibilità e nessun controllo.

Tre errori che dicono tutti “bloccato”

Chromium ne ha diversi, non sono intercambiabili, e la differenza è interamente su chi ha fatto il blocco. Questi sono i tre che vale la pena conoscere, con le descrizioni dall’elenco di errori stesso:

• ERR_BLOCKED_BY_CLIENT: “Il client ha scelto di bloccare la richiesta.” Qualcosa sulla macchina dell’utente. Non la tua, e non quella dell’altro sito.
• ERR_BLOCKED_BY_CSP: “La richiesta è stata bloccata da una Content Security Policy.” La tua policy, o una che un proxy ha aggiunto strada facendo.
• ERR_BLOCKED_BY_RESPONSE: la risposta è arrivata portando requisiti che non sono stati soddisfatti, come X-Frame-Options, controlli degli antenati di Content-Security-Policy o Cross-Origin-Resource-Policy. Quella è la decisione dell’altro capo.

Tre errori, tre proprietari: la macchina dell’utente, la tua policy, le loro intestazioni. Solo quello di mezzo è tuo da correggere, ed è quello che le persone raggiungono per ultimo. Una quarta famiglia è confusa con queste abbastanza spesso da valere la pena separare anche: un errore CORS non è un blocco affatto, è una risposta che il browser ha ottenuto e poi si è rifiutato di consegnare al tuo codice.

Che cosa vede il tuo JavaScript, che è quasi niente

Ecco la parte che rende questo costoso. Una richiesta bloccata non arriva nel tuo codice come “bloccata”.

fetch() rifiuta con un TypeError, e MDN è esplicito che questo è quello che ottieni per un errore di rete in generale, “ad esempio, perché il dispositivo non ha connettività”. Lo stesso rifiuto copre un URL malformato, un dispositivo veramente offline, e una richiesta che un’estensione si è rifiutata di inviare. La promise non porta nessuna ragione, quindi non c’è niente nel rifiuto per distinguere questi.

Vale la pena ricordare che cosa non rifiuta mentre sei qui: uno stato di errore HTTP non lo fa. Un 404 o un 504 si risolve normalmente e ti lascia a controllare response.ok. Quindi il fallimento che produce le meno informazioni nel tuo codice è quello dove la richiesta non ha mai lasciato la macchina, e i fallimenti che producono di più sono quelli che il tuo server ha gestito.

Se vuoi la distinzione, il browser ce l’ha. Il pannello di rete mostra la richiesta con accanto l’errore di rete, e chrome://net-export lo cattura. Entrambi quelli sono sul computer dell’utente, che è il problema di cui tratta tutto questo articolo.

Perché è così difficile da riprodurre

Non puoi riprodurlo, per costruzione, perché la causa non è nel tuo sistema. È in una configurazione che esiste su una macchina, scelta da qualcuno che potrebbe non ricordare di aver scelto, e forse installata dal suo datore di lavoro.

Quindi il ciclo va: un utente segnala che il salvataggio non fa niente, apri la pagina, il salvataggio funziona, chiudi il ticket. L’utente non si sbaglia e nemmeno tu. La differenza è un elenco di host bloccati che non puoi vedere.

Chiedergli di disabilitare le estensioni a volte funziona ed è uno strumento scarso. Chiede a una persona di sperimentare sul suo browser per tuo conto, trova solo il caso dell’estensione, e un dispositivo gestito non glielo permetterà affatto.

Il registro di rete è quello che lo risolve, perché la richiesta rifiutata ci sta dentro con accanto l’errore. Questo trasforma “il salvataggio non fa niente” in “questa richiesta a questo host non ha mai lasciato la loro macchina”, che è una conversazione diversa e di solito una breve.

Che cosa fare

Aspettati questo su qualsiasi cosa che sembra un tracciamento. Host con analytics, metrics, telemetry, beacon o ads nel nome sono bloccati per impostazione predefinita dalle liste comuni. Lo sono anche i percorsi. Se la tua stessa segnalazione degli errori vive su un host del genere, i rapporti su di esso sono quelli che non riceverai mai.

Non lasciare che una richiesta bloccata rompa la pagina. Una chiamata di analytics bloccata non dovrebbe fermare l’invio di un modulo. Separa la richiesta che conta dalla richiesta che è bello avere, e lascia che la seconda fallisca in silenzio.

Tratta l’assenza di dati come dati. Meno eventi da un sottoinsieme di utenti è uno dei pochi segnali che questo lascia dietro, e si legge come una settimana tranquilla piuttosto che come un guasto.

In un paragrafo

ERR_BLOCKED_BY_CLIENT significa che qualcosa sulla macchina del visitatore, di solito un’estensione e a volte il software del suo datore di lavoro, ha deciso che la tua richiesta non sarebbe stata inviata. Il tuo server non l’ha mai vista, fetch la segnala come lo stesso TypeError che usa per un dispositivo offline, e l’unico record è su un computer che non hai. Non è lo stesso di un blocco di policy che possiedi o di un’intestazione che l’altro capo ha inviato, e distinguere questi tre è la maggior parte del lavoro.