HTTP-Statuscode 0 - Fehlerdomäne = NSURLErrorDomain?

Ich arbeite an einem iOS-Projekt.

In dieser Anwendung lade ich Bilder vom Server herunter.

Problem:

Beim Herunterladen von Bildern wird ein Zeitlimit für die Anforderung angezeigt . Laut Dokumentation ist der HTTP-Statuscode des Anforderungszeitlimits 408.

In meiner Anwendung erhalte ich jedoch den HTTP-Statuscode 0mit dem folgenden Fehler

Error Domain = NSURLErrorDomain Code = -1001 "Die Anforderung ist abgelaufen." 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 = Die Anforderung Zeitüberschreitung ., NSUnderlyingError = 0x13846870 "Die Anforderung ist abgelaufen."}

Während einer Suche über das Internet habe ich keine Informationen zum HTTP-Statuscode 0 gefunden.

Kann mir das jemand erklären?

Es gibt keinen HTTP-Statuscode 0. Sie sehen eine 0, die von der von Ihnen verwendeten API / Bibliothek zurückgegeben wird. Sie müssen die Dokumentation dafür überprüfen.

Ein Statuscode von 0 in einem NSHTTPURLResponseObjekt bedeutet im Allgemeinen, dass keine Antwort erfolgt ist, und kann aus verschiedenen Gründen auftreten. Der Server gibt niemals den Status 0 zurück, da dies kein gültiger HTTP-Statuscode ist.

In Ihrem Fall erscheinen Sie der Statuscode 0 angezeigt, da die Anforderung abgelaufen ist und 0 nur der Standardwert für die Eigenschaft ist. Das Zeitlimit selbst kann verschiedene Gründe haben, z. B. weil der Server einfach nicht rechtzeitig reagiert, von einer Firewall blockiert wird oder Ihre gesamte Netzwerkverbindung unterbrochen ist. Im letzteren Fall ist das Telefon normalerweise intelligent genug, um zu wissen, dass es keine Netzwerkverbindung hat und sofort ausfällt. Es wird jedoch immer noch mit einem scheinbaren Statuscode von 0 fehlschlagen.

Beachten Sie, dass in Fällen, in denen der Statuscode 0 ist, der tatsächliche Fehler im zurückgegebenen NSErrorObjekt erfasst wird, nicht im NSHTTPURLResponse.

Der HTTP-Status 408ist meiner Erfahrung nach ziemlich ungewöhnlich. Ich habe selbst noch nie einen getroffen. Es wird jedoch anscheinend in Fällen verwendet, in denen der Client eine aktive Socket-Verbindung zum Server aufrechterhalten muss und der Server darauf wartet, dass der Client weitere Daten über den offenen Socket sendet, dies jedoch nicht in einer bestimmten Zeit und Der Server beendet die Verbindung mit einem 408Statuscode, der dem Client im Wesentlichen mitteilt, dass Sie zu lange gebraucht haben.

Die Antwort war leer. In den meisten Fällen werden die Codes mit 1xx, 2xx, 3xx, 4xx, 5xx angegeben.

Liste der HTTP-Statuscodes

Im iOS SDK Wenn Ihre API-Aufrufe eine Zeitüberschreitung aufweist, erhalten Sie dafür den Status 0.

Aufgrund meiner begrenzten Erfahrung würde ich sagen, dass die folgenden beiden Szenarien zu Reaktionen führen status code: 0können. es könnte mehr sein, aber ich kenne diese beiden:

• Ihre Verbindung reagiert möglicherweise langsam.
• oder vielleicht ist der Back-End-Server nicht verfügbar.

Die Sache ist, status: 0ist etwas allgemein gehalten, und es könnten mehr Anwendungsfälle sein, die einen leeren Antwortkörper auslösen.

Der Statuscode '0' kann aus drei Gründen auftreten:
1) Der Client kann keine Verbindung zum Server herstellen.
2) Der Client kann die Antwort nicht innerhalb des Zeitlimits empfangen.
3) Die Anforderung wurde vom Client "gestoppt (abgebrochen)" .

Diese drei Gründe sind jedoch nicht standardisiert

HTTP-Antwort 0 ist keine Standard-HTTP-Antwort. Es zeigt jedoch an, dass der Client keine Verbindung zum Server herstellen konnte und daher eine vierte Zeitüberschreitung auftrat.

Wir haben den Fehler bekommen:

GET http: //localhost/pathToWebSite/somePage.aspx hat einen http.status: 0-Fehler ausgelöst

Dieser Aufruf erfolgt über eine Windows-Task, die eine VBS-Datei aufruft. Um das Problem zu beheben, hat ein Browser auf die URL verwiesen, und es wird ein Datenschutzfehler angezeigt:

Ihre Verbindung ist nicht privat

Angreifer versuchen möglicherweise, Ihre Informationen von localhost zu stehlen (z. B. Passwörter, Nachrichten oder Kreditkarten). NET :: ERR_CERT_COMMON_NAME_INVALID

Melden Sie automatisch Details möglicher Sicherheitsvorfälle an Google. Datenschutzrichtlinie Zurück zur Sicherheit Dieser Server konnte nicht beweisen, dass es sich um localhost handelt. Das Sicherheitszertifikat stammt von * .ourdomain.com. Dies kann durch eine Fehlkonfiguration oder einen Angreifer verursacht werden, der Ihre Verbindung abfängt. Mehr erfahren.

Dies liegt daran, dass wir einen IIS-URL-Rewrite-Regelsatz haben, um die Verwendung von https für Verbindungen zu erzwingen. Diese Regel leitet http: // localhost zu https: // localhost um, aber unser SSL-Zertifikat basiert auf einem nach außen gerichteten Domainnamen, nicht localhost, daher der Fehler, der als Statuscode 0 gemeldet wird. Ein Datenschutzfehler kann daher ein sehr unklarer Grund sein für diesen Statuscode 0.

In unserem Fall bestand die Lösung darin, der Regel für localhost eine Ausnahme hinzuzufügen und http: //localhost/pathToWebSite/somePage.aspx die Verwendung von http zu ermöglichen. Obskur, ja, aber ich werde nächstes Jahr darauf stoßen und jetzt werde ich meine Antwort in einer Google-Suche finden.

Manchmal antwortet der Browser auf die http-Fehlerbehandlungsroutine mit einem Fehlerobjekt, dessen Status auf 0 gesetzt ist, selbst wenn im Netzwerk der Fehlerstatus 404, 401, 500 usw. angezeigt wird.

Dies kann passieren, wenn sich Ihre Anwendung und API in verschiedenen Domänen befinden - der CORS-Mechanismus wird angewendet. Laut CORS sendet der Browser für jede API-Anfrage zwei Anfragen:

1. Preflight OPTIONS-Anfrage, um zu verstehen, ob die API die Actual / Origin-Anfrage zulässt.
2. Wenn die API dies zulässt (OPTIOS-Anfrage mit Status 204 und korrekten Access-Control-Allow-Origin-Headern antworten), sendet der Browser die nächste "Actual / Origin-Anfrage".

In der Anwendung wird die Fehlerantwort für "Ist- / Ursprungsanforderung" verarbeitet. Wenn die "Preflight-OPTIONS-Anforderung" fehlgeschlagen ist, gibt der Browser kein korrektes HttpError-Objekt für die http-Fehlerbehandlungsroutine aus. Um den korrekten Status der http-Antwort zu erhalten, stellen Sie sicher, dass Sie eine erfolgreiche Preflight-OPTIONS-Anforderungsantwort erhalten.

CORS in meinem Fall.

Ich hatte einmal eine solche Antwort in einer iOS-App. Die Lösung war das Fehlen Access-Control-Allow-Origin: *in den Headern.

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

Dies kann bei einer 401-http-Antwort passieren, wenn NSURLConnection verwendet wird.

Siehe NSURLConnection-Rückgabefehler anstelle der Antwort für 401

Bei einem Timeout für den Gate-Weg ist der Status bei Ihrem Fehlerrückruf Null.

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

HTTP-Statuscodes