Code d'état HTTP 0 - Domaine d'erreur = NSURLErrorDomain?

Je travaille sur un projet iOS.

Dans cette application, je télécharge des images depuis le serveur.

Problème:

Pendant le téléchargement des images, je reçois le délai d'expiration de la demande . Selon la documentation, le code d'état HTTP du délai d'expiration de la demande est 408.

Mais dans mon application, j'obtiens un code d'état HTTP 0avec l'erreur suivante

Domaine d'erreur = NSURLErrorDomain Code = -1001 "La demande a expiré." UserInfo = 0xb9af710 {NSErrorFailingURLStringKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSErrorFailingURLKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg = La description de la requête NSLocalized ., NSUnderlyingError = 0x13846870 "La requête a expiré."}

Lors d'une recherche, sur Internet, je n'ai trouvé aucune information sur le code d'état HTTP 0.

Quelqu'un peut-il m'expliquer cela?

Il n'y a pas de code d'état HTTP 0. Ce que vous voyez est un 0 renvoyé par l'API / la bibliothèque que vous utilisez. Vous devrez vérifier la documentation pour cela.

Un code d'état de 0 dans un NSHTTPURLResponseobjet signifie généralement qu'il n'y a pas eu de réponse et peut se produire pour diverses raisons. Le serveur ne retournera jamais un état de 0 car ce n'est pas un code d'état HTTP valide.

Dans votre cas, vous semblez obtenir un code d'état de 0 car la demande expire et 0 est simplement la valeur par défaut de la propriété. Le délai lui-même peut être dû à diverses raisons, telles que le serveur ne répond tout simplement pas à temps, est bloqué par un pare-feu ou toute votre connexion réseau est interrompue. Habituellement, dans le cas de ce dernier, le téléphone est suffisamment intelligent pour savoir qu'il n'a pas de connexion réseau et qu'il échouera immédiatement. Cependant, il échouera toujours avec un code d'état apparent de 0.

Notez que dans les cas où le code d'état est 0, l'erreur réelle est capturée dans l' NSErrorobjet retourné , pas dans le fichier NSHTTPURLResponse.

Le statut HTTP 408est assez rare dans mon expérience. Je n'en ai jamais rencontré moi-même. Mais il est apparemment utilisé dans les cas où le client a besoin de maintenir une connexion de socket active au serveur, et le serveur attend que le client envoie plus de données sur le socket ouvert, mais ce n'est pas le cas dans un laps de temps donné et le serveur termine la connexion avec un 408code d'état, indiquant essentiellement au client "vous avez pris trop de temps".

La réponse était vide. Dans la plupart des cas, les codes seront statistiques avec 1xx, 2xx, 3xx, 4xx, 5xx.

Liste des codes d'état HTTP

Dans le SDK iOS Lorsque votre appel API expire, vous obtenez le statut 0 pour cela.

D'après mon expérience limitée, je dirais que les deux scénarios suivants pourraient provoquer une réponse status code: 0, gardez à l'esprit; leur pourrait être plus, mais je connais ces deux:

• votre connexion répond peut-être lentement.
• ou peut-être que le serveur principal n'est pas disponible.

le fait est, status: 0est légèrement générique, et il pourrait y avoir plus de cas d'utilisation qui déclenchent un corps de réponse vide.

Le code d'état '0' peut se produire pour trois raisons
1) Le client ne peut pas se connecter au serveur
2) Le client ne peut pas recevoir la réponse dans le délai d'expiration
3) La demande a été "arrêtée (abandonnée)" par le client.

Mais ces trois raisons ne sont pas standardisées

La réponse HTTP 0 n'est pas une réponse HTTP standard. Mais cela indique que le client n'a pas pu se connecter au serveur et donc un délai d'attente s'est produit.

Nous avons eu l'erreur:

AVOIR http: //localhost/pathToWebSite/somePage.aspx a généré une erreur http.status: 0

Cet appel est effectué à partir d'une tâche Windows qui appelle un fichier VBS, donc pour résoudre le problème, pointez un navigateur vers l'URL et nous obtenons une erreur de confidentialité:

Votre connexion n'est pas privée

Les attaquants peuvent essayer de voler vos informations à l'hôte local (par exemple, des mots de passe, des messages ou des cartes de crédit). NET :: ERR_CERT_COMMON_NAME_INVALID

Signalez automatiquement les détails des éventuels incidents de sécurité à Google. Politique de confidentialité Retour à la sécurité Ce serveur n'a pas pu prouver qu'il s'agit d'un hôte local; son certificat de sécurité provient de * .ourdomain.com. Cela peut être dû à une mauvaise configuration ou à un attaquant interceptant votre connexion. Apprendre encore plus.

En effet, nous avons une règle de réécriture d'URL IIS définie pour forcer les connexions à utiliser https. Cette règle détourne http: // localhost vers https: // localhost mais notre certificat SSL est basé sur un nom de domaine extérieur non localhost, donc l'erreur qui est signalée comme code d'état 0. Une erreur de confidentialité pourrait donc être une raison très obscure pour ce code d'état 0.

Dans notre cas, la solution était d'ajouter une exception à la règle pour localhost et d'autoriser http: //localhost/pathToWebSite/somePage.aspx à utiliser http. Obscur, oui, mais je vais rencontrer cela l'année prochaine et maintenant je trouverai ma réponse dans une recherche Google.

Parfois, le navigateur répond au gestionnaire d'erreurs http avec un objet d'erreur, dont l'état est défini sur 0, même si vous pouvez voir l'état d'erreur 404, 401, 500, etc. dans le réseau.

Cela peut se produire si votre application et votre API sont sur des domaines différents - le mécanisme CORS est appliqué. Selon CORS pour chaque requête d'API, le navigateur envoie deux requêtes:

1. demande OPTIONS de contrôle en amont pour comprendre si l'API autorise la demande réelle / d'origine
2. lorsque l'API le permet (la requête OPTIOS répond avec l'état 204 et les en-têtes Access-Control-Allow-Origin corrects) - le navigateur envoie la prochaine "Requête réelle / d'origine".

Dans l'application, nous gérons la réponse d'erreur pour la "demande réelle / d'origine", et si la "demande OPTIONS de contrôle en amont" a échoué - le navigateur ne donne pas l'objet HttpError correct pour le gestionnaire d'erreurs http. Donc, pour obtenir le statut correct de la réponse http, assurez-vous d'obtenir une réponse à la demande OPTIONS de contrôle en amont.

CORS dans mon cas.

J'ai eu une telle réponse dans une application iOS une fois. La solution était le manque Access-Control-Allow-Origin: *dans les en-têtes.

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

Cela peut se produire avec une réponse http 401 si vous utilisez NSURLConnection.

Voir NSURLConnection renvoyant une erreur au lieu de la réponse pour 401

Lors de l'expiration du délai de passage de la porte, l'état sera nul lors de votre rappel d'erreur.

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

Codes d'état HTTP