HTTP-statuscode 0 – Fout-domein = nsurlerrordomain?

Ik werk aan een IOS-project.

In deze toepassing download ik afbeeldingen van de server.

probleem:

Tijdens het downloaden van afbeeldingen, word ik aanvragen time-out . Volgens de Documentatie is HTTP-statuscode van aanvraag Time-out 408.

Maar in mijn toepassing krijg ik HTTP Status Code 0met de volgende fout

ERROR DOMAIN = NSURLERRORDOMAIN CODE = -1001 “Het aanvraag verlopen.”
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 = het aanvraag verlopen.,
NsOnderlyingError = 0x13846870 “Het aanvraag verlopen.”}

Tijdens een zoekopdracht, via internet vond ik geen informatie over HTTP Status Code 0.

Kan iemand dit aan mij uitleggen?


Antwoord 1, Autoriteit 100%

Er is geen HTTP-statuscode 0. Wat u ziet is een 0 geretourneerd door de API / Library die u gebruikt. U moet de documentatie daarvoor controleren.


Antwoord 2, Autoriteit 77%

Een statuscode van 0 in een NSHTTPURLResponseobject betekent in het algemeen dat er geen reactie was en om verschillende redenen kan optreden. De server zal nooit een status van 0 retourneren, omdat dit geen geldige HTTP-statuscode is.

In uw geval lijkt ueen statuscode van 0 te krijgen omdat het verzoek een time-out heeft en 0 slechts de standaardwaarde voor de eigenschap is. De time-out zelf kan verschillende redenen hebben, zoals dat de server gewoon niet op tijd reageert, wordt geblokkeerd door een firewall of dat uw hele netwerkverbinding uitvalt. Meestal in het laatste geval, hoewel de telefoon slim genoeg is om te weten dat hij geen netwerkverbinding heeft en onmiddellijk zal falen. Het zal echter nog steeds mislukken met een schijnbare statuscode van 0.

Merk op dat in gevallen waarin de statuscode 0 is, de echte fout wordt vastgelegd in het geretourneerde NSError-object, niet in de NSHTTPURLResponse.

HTTP-status 408is vrij ongebruikelijk in mijn ervaring. Ik ben er zelf nog nooit een tegengekomen. Maar het wordt blijkbaar gebruikt in gevallen waarin de client een actieve socketverbinding met de server moet onderhouden en de server wacht op de client om meer gegevens over de open socket te verzenden, maar dit niet binnen een bepaalde tijd en de server beëindigt de verbinding met een 408statuscode, die de klant in feite vertelt “je duurde te lang”.


Antwoord 3, autoriteit 11%

Het antwoord was leeg.
Meestal worden de codes weergegeven met 1xx, 2xx, 3xx, 4xx, 5xx.

Lijst met HTTP-statuscodes


Antwoord 4, autoriteit 11%

In iOS SDK Wanneer uw API-aanroep time-outs krijgt, krijgt u daarvoor status 0.


Antwoord 5, autoriteit 6%

Statuscode ‘0’ kan om drieredenen voorkomen

1) De Client kan geen verbinding maken met de server

2) De klant kan het antwoord niet ontvangenbinnen de time-outperiode

3) Het verzoek is “stopped(aborted)”door de klant.

Maar deze drie redenen zijn niet gestandaardiseerd


Antwoord 6, autoriteit 5%

Vanuit mijn beperkte ervaring zou ik zeggen dat de volgende twee scenario’s een reactie status code: 0, houd er rekening mee; er kunnen er meer zijn, maar ik ken die twee:

  • je verbinding reageert misschien traag.
  • of misschien is de back-end server niet beschikbaar.

het punt is, status: 0is enigszins generiek, en er kunnen meer use-cases zijn die een lege reactietekst veroorzaken.


Antwoord 7, autoriteit 4%

HTTP-antwoord 0 is geen standaard HTTP-antwoord. Maar het geeft aan dat de client geen verbinding kon maken met de server en dat er dus een time-out was opgetreden.


Antwoord 8, autoriteit 3%

Soms reageert de browser op http-fouthandler met Error Object, waarvan de status is ingesteld op 0, zelfs als u de foutstatus 404, 401, 500 enz. in het netwerk kunt zien.

Dit kan gebeuren als uw applicatie en API zich op verschillende domeinen bevinden – het CORS-mechanisme wordt toegepast.
Volgens CORS verzendt de browser voor elk API-verzoek twee verzoeken:

  1. preflight OPTIONS-verzoek om te begrijpen of API Actual/Origin-verzoek toestaat.
  2. wanneer API dit toestaat (OPTIOS-verzoek reageert met status 204 en correcte Access-Control-Allow-Origin-headers) – browser verzendt volgende “Actual/Origin-verzoek”.

In de toepassing verwerken we een foutreactie voor “Actual/Origin request”, en als “preflight OPTIONS request” is mislukt, geeft de browser geen correct HttpError-object voor de http-fouthandler.
Dus om de juiste status van de http-reactie te krijgen, zorg ervoor dat u een succes-preflight OPTIES-verzoekreactie krijgt.


Antwoord 9, autoriteit 2%

We hebben de fout:

GET http://localhost/pathToWebSite/somePage.aspxdeed een http.status: 0 fout

Die aanroep wordt gedaan vanuit een Windows-taak die een VBS-bestand aanroept, dus om het probleem op te lossen, wees een browser naar de url en we krijgen een privacyfout:

Uw verbinding is niet privé

Aanvallers proberen mogelijk uw informatie van localhost te stelen
(bijvoorbeeld wachtwoorden, berichten of creditcards).
NET::ERR_CERT_COMMON_NAME_INVALID

Automatisch details van mogelijke beveiligingsincidenten rapporteren aan Google.
Privacybeleid Terug naar veiligheid Deze server kon dat niet bewijzen
lokale host; het beveiligingscertificaat is van *.ourdomain.com. Dit zou
worden veroorzaakt door een verkeerde configuratie of een aanvaller die uw
verbinding. Meer informatie.

Dit komt omdat we een IIS URL Rewrite-regel hebben ingesteld om verbindingen af te dwingen https. Die regel leidt http://localhostom naar https ://localhostmaar ons SSL-certificaat is gebaseerd op een naar buiten gerichte domeinnaam en niet op localhost, dus de fout die wordt gerapporteerd als statuscode 0. Een privacyfout kan dus een zeer obscure reden zijn voor deze statuscode 0.

In ons geval was de oplossing om een uitzondering toe te voegen aan de regel voor localhost en toe te staan http://localhost/ pathToWebSite/somePage.aspxom http te gebruiken. Obscure, ja, maar ik kom dit volgend jaar tegen en nu zal ik mijn antwoord vinden in een Google-zoekopdracht.


Antwoord 10

CORS in mijn geval.

Ik heb ooit zo’n reactie gehad in een iOS-app. De oplossing was de ontbrekende Access-Control-Allow-Origin: *in de headers.

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


Antwoord 11

Dit kan gebeuren met een 401 http-antwoord bij gebruik van NSURLConnection.

Zie NSURLConnection geeft fout terug in plaats van antwoord voor 401

Other episodes