Risposta breve
Non è un codice di risposta HTTP, ma è documentato da WhatWG come un valore valido per l'attributo di stato di una XMLHttpRequestrisposta o Fetch.
In generale, è un valore predefinito utilizzato quando non è presente un codice di stato HTTP reale da segnalare e / o si è verificato un errore durante l'invio della richiesta o la ricezione della risposta. Possibili scenari in cui questo è il caso includono, ma non sono limitati a:
- La richiesta non è stata ancora inviata o è stata interrotta.
- Il browser è ancora in attesa di ricevere lo stato della risposta e le intestazioni.
- La connessione si è interrotta durante la richiesta.
- La richiesta è scaduta.
- La richiesta ha rilevato un ciclo di reindirizzamento infinito.
- Il browser conosce lo stato della risposta, ma non ti è consentito accedervi a causa delle limitazioni di sicurezza relative alla politica della stessa origine .
Risposta lunga
Innanzitutto, per ribadire: 0 non è un codice di stato HTTP. C'è un elenco completo di questi nella sezione 6.1 della RFC 7231 , che non include 0, e l'introduzione alla sezione 6 afferma chiaramente che
L'elemento codice di stato è un codice intero a tre cifre
quale 0 non è.
Tuttavia, 0 come valore .statusdell'attributo di un oggetto XMLHttpRequest è documentato, sebbene sia un po 'complicato rintracciare tutti i dettagli rilevanti. Iniziamo da https://xhr.spec.whatwg.org/#the-status-attribute , documentando l' .statusattributo, che afferma semplicemente:
L' statusattributo deve restituire la risposta ‘s stato .
Può sembrare vacuo e tautologico, ma in realtà ci sono informazioni qui! Ricorda che questa documentazione qui parla .responsedell'attributo di un XMLHttpRequest, non di una risposta, quindi questo ci dice che la definizione dello stato su un oggetto XHR è rimandata alla definizione dello stato di una risposta nelle specifiche Fetch.
Ma quale oggetto risposta? E se non abbiamo ancora ricevuto una risposta? Il link in linea sulla parola "risposta" ci porta a https://xhr.spec.whatwg.org/#response , che spiega:
An XMLHttpRequestha una risposta associata. Salvo diversa indicazione, si tratta di un errore di rete .
Quindi la risposta di cui stiamo ottenendo lo stato è per impostazione predefinita un errore di rete. E cercando ovunque la frase "imposta risposta a" sia utilizzata nelle specifiche XHR, possiamo vedere che è impostata in cinque posizioni:
Guardando nello standard Fetch , possiamo vedere che:
Un errore di rete è una risposta il cui stato è sempre0
quindi possiamo immediatamente dire che vedremo uno stato di 0 su un oggetto XHR in uno qualsiasi dei casi in cui la specifica XHR dice che la risposta dovrebbe essere impostata su un errore di rete. (È interessante notare che questo include il caso in cui il flusso del corpo viene "errato", che la specifica Fetch ci dice può accadere durante l'analisi del corpo dopo aver ricevuto lo stato - quindi in teoria suppongo sia possibile che un oggetto XHR abbia il suo stato impostato su 200, quindi si verifica un errore di memoria insufficiente o qualcosa del genere durante la ricezione del corpo e quindi cambia il suo stato di nuovo a 0.)
Notiamo anche nello standard Fetch che esistono un paio di altri tipi di risposta il cui stato è definito come 0, la cui esistenza è correlata alle richieste cross-origin e alla policy della stessa origine:
Una risposta filtrata opaca è una risposta filtrata il cui stato 0... è ...
Una risposta filtrata di reindirizzamento opaco è una risposta filtrata il cui stato 0... è ...
(sono stati omessi vari altri dettagli su questi due tipi di risposta).
Ma oltre a questi, ci sono anche molti casi in cui l' algoritmo Fetch (piuttosto che la specifica XHR, che abbiamo già esaminato) richiede che il browser restituisca un errore di rete! In effetti, la frase "restituisci un errore di rete" appare 40 volte nello standard Fetch. Non cercherò di elencare tutti i 40 qui, ma noto che includono:
- Il caso in cui lo schema della richiesta non è riconosciuto (es. Tentativo di inviare una richiesta a madeupscheme: //foobar.com)
- L'istruzione meravigliosamente vaga "In caso di dubbio, restituisci un errore di rete". negli algoritmi per la gestione degli URL ftp: // e file: //
- Reindirizzamenti infiniti: "Se il numero di reindirizzamenti della richiesta è venti, restituisce un errore di rete."
- Una serie di problemi relativi a CORS, come "Se la contaminazione della risposta di httpRequest non è" cors "e la politica delle risorse tra le origini controlla con i ritorni di richiesta e risposta bloccati, restituisce un errore di rete".
- Errori di connessione: "Se la connessione non riesce, restituisci un errore di rete."
In altre parole: ogni volta che qualcosa va storto altro che ottenere un codice di stato HTTP vero errore come un 500 o 400 dal server, si finisce con un attributo status di 0 sul vostro oggetto XHR o Fetch oggetto risposta nel browser. Il numero di possibili cause specifiche elencate nelle specifiche è vasto.
Infine: se sei interessato alla storia della specifica per qualche motivo, nota che questa risposta è stata completamente riscritta nel 2020 e che potresti essere interessato alla precedente revisione di questa risposta , che ha analizzato essenzialmente le stesse conclusioni dal specifiche W3 più vecchie (e molto più semplici) per XHR, prima che queste fossero sostituite dalle specifiche WhatWG più moderne e più complicate a cui si riferisce questa risposta.