Codice di stato HTTP 0 - Error Domain = NSURLErrorDomain?

Sto lavorando a un progetto iOS.

In questa applicazione, sto scaricando immagini dal server.

Problema:

Durante il download delle immagini ricevo Timeout richiesta . Secondo la documentazione, il codice di stato HTTP del timeout della richiesta è 408.

Ma nella mia applicazione, ricevo il codice di stato HTTP 0con il seguente errore

Error Domain = NSURLErrorDomain Code = -1001 "La richiesta è scaduta." UserInfo = 0xb9af710 {NSErrorFailingURLStringKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSErrorFailingURLKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSLocalizedDescription = The request timed out ., NSUnderlyingError = 0x13846870 "La richiesta è scaduta."}

Durante una ricerca, su Internet, non ho trovato informazioni sul codice di stato HTTP 0.

Qualcuno può spiegarmi questo?

Non esiste un codice di stato HTTP 0. Quello che vedi è uno 0 restituito dall'API / libreria che stai utilizzando. Dovrai controllare la documentazione per questo.

Un codice di stato 0 in un NSHTTPURLResponseoggetto generalmente significa che non c'è stata risposta e può verificarsi per vari motivi. Il server non restituirà mai uno stato 0 poiché non si tratta di un codice di stato HTTP valido.

Nel tuo caso, sembra che tu riceva un codice di stato 0 perché la richiesta è scaduta e 0 è solo il valore predefinito per la proprietà. Il timeout stesso potrebbe essere dovuto a vari motivi, ad esempio il server semplicemente non risponde in tempo, essere bloccato da un firewall o l'intera connessione di rete non funzionante. Di solito in quest'ultimo caso il telefono è abbastanza intelligente da sapere che non ha una connessione di rete e non funzionerà immediatamente. Tuttavia, fallirà comunque con un codice di stato apparente pari a 0.

Si noti che nei casi in cui il codice di stato è 0, l'errore reale viene catturato NSErrornell'oggetto restituito , non nel file NSHTTPURLResponse.

Stato HTTP 408 è piuttosto raro nella mia esperienza. Non ne ho mai incontrato uno nemmeno io. Ma è apparentemente utilizzato nei casi in cui il client deve mantenere una connessione socket attiva al server, e il server sta aspettando che il client invii più dati sul socket aperto, ma non lo fa in un dato periodo di tempo e il server termina la connessione con un 408codice di stato, essenzialmente dicendo al client "hai impiegato troppo tempo".

La risposta era vuota. Nella maggior parte dei casi, i codici presenteranno 1xx, 2xx, 3xx, 4xx, 5xx.

Elenco dei codici di stato HTTP

In iOS SDK Quando la tua API chiama timeout, ottieni lo stato 0 per questo.

Dalla mia limitata esperienza, direi che i seguenti due scenari potrebbero causare una risposta status code: 0, tieni presente; potrebbero essere di più, ma io so di quei due:

• la tua connessione forse risponde lentamente.
• o forse il server back-end non è disponibile.

il fatto è che status: 0è leggermente generico e potrebbero essere più casi d'uso che attivano un corpo di risposta vuoto.

Il codice di stato '0' può verificarsi per tre motivi
1) Il client non può connettersi al server
2) Il client non può ricevere la risposta entro il periodo di timeout
3) La richiesta è stata "interrotta (interrotta)" dal client.

Ma questi tre motivi non sono standardizzati

La risposta HTTP 0 non è una risposta HTTP standard. Ma indica che il client non è riuscito a connettersi al server e quindi si è verificato un timeout.

Abbiamo ricevuto l'errore:

GET http: //localhost/pathToWebSite/somePage.aspx ha generato un errore http.status: 0

Quella chiamata viene effettuata dall'attività di Windows che chiama un file VBS, quindi per risolvere il problema, punta un browser all'URL e otteniamo un errore di privacy:

La tua connessione non è privata

Gli aggressori potrebbero tentare di rubare le tue informazioni da localhost (ad esempio, password, messaggi o carte di credito). NET :: ERR_CERT_COMMON_NAME_INVALID

Segnala automaticamente i dettagli di possibili incidenti di sicurezza a Google. Tutela dei dati personali Torna alla sicurezza Questo server non ha potuto dimostrare di essere localhost; il suo certificato di sicurezza proviene da * .ourdomain.com. Ciò potrebbe essere causato da una configurazione errata o da un malintenzionato che intercetta la tua connessione. Per saperne di più.

Questo perché abbiamo una regola di riscrittura URL IIS impostata per forzare le connessioni a utilizzare https. Questa regola devia http: // localhost a https: // localhost ma il nostro certificato SSL si basa su un nome di dominio rivolto all'esterno non localhost, quindi l'errore che viene segnalato come codice di stato 0. Quindi un errore di privacy potrebbe essere un motivo molto oscuro per questo codice di stato 0.

Nel nostro caso la soluzione era aggiungere un'eccezione alla regola per localhost e consentire a http: //localhost/pathToWebSite/somePage.aspx di utilizzare http. Oscuro, sì, ma mi imbatterò nel prossimo anno e ora troverò la mia risposta in una ricerca su Google.

A volte il browser risponde al gestore degli errori http con un oggetto errore, che ha lo stato impostato su 0, anche se è possibile visualizzare lo stato di errore 404, 401, 500 ecc. Nella rete.

Ciò potrebbe accadere se la tua applicazione e API si trovano su domini diversi: viene applicato il meccanismo CORS. Secondo CORS per ogni richiesta API il browser invia due richieste:

1. richiesta OPZIONI di preflight per capire se l'API consente la richiesta effettiva / origine.
2. quando l'API lo consente (la richiesta OPTIOS risponde con lo stato 204 e le intestazioni Access-Control-Allow-Origin corrette) - il browser invia la successiva "richiesta Actual / Origin".

Nell'applicazione stiamo gestendo la risposta di errore per "Richiesta effettiva / origine" e se la "richiesta OPZIONI di preflight" non è riuscita, il browser non fornisce l'oggetto HttpError corretto per il gestore degli errori http. Quindi, per ottenere lo stato corretto della risposta http, assicurati di ottenere una risposta alla richiesta di OPZIONI di preflight riuscita.

CORS nel mio caso.

Una volta ho avuto una tale risposta in un'app iOS. La soluzione era la mancanza Access-Control-Allow-Origin: *nelle intestazioni.

Altro: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

Ciò può accadere con una risposta http 401 se si utilizza NSURLConnection.

Vedere NSURLConnection che restituisce l'errore invece della risposta per 401

Al timeout del gate way, lo stato sarà zero alla chiamata di errore.

.error( function( data,status,headers,config){
    console.log(status) 
 }

Codici di stato HTTP