J'obtiens l'erreur "NSURLErrorDomain Code = -1004" avec les appels d'API Alamofire, Mais seulement quelques secondes après le démarrage de l'application (ou a pris une pause de quelques minutes pendant que l'application est ouverte et passe un appel après cela. )
Si j'essaie de faire le même appel après quelques secondes, tout fonctionne correctement . J'ai cherché toutes les questions relatives au débordement de pile et vérifié toutes les causes possibles ci-dessous:
Mon sentiment est que l’obtention des paramètres réseau prend quelques secondes et que lorsque je passe un appel API avant que cela soit fait, cela échoue immédiatement. OU .. J'utilise un Websocket en arrière-plan qui pourrait être lié?
FAILURE: Error Domain = NSURLErrorDomain Code = -1004 "Impossible de se connecter au serveur." UserInfo = {NSUnderlyingError = 0x137d39380 {Error Domain = kCFErrorDomainCF Code de réseau = -100100 " NSErrorFailingURLStringKey = [FILTRÉ], NSErrorFailingURLKey = [FILTRÉ], _kCFStreamErrorDomainKey = 4, _kCFStreamErrorCodeKey = -2200, NSLocalizedDescription = Impossible de se connecter au serveur.}
Aucune suggestion?
MIS À JOUR
Nous avons constaté que l'application effectuait 4 demandes au lancement et que 1 ou 2 d'entre elles échouaient de manière aléatoire. J'ai vérifié l'accès au journal Nginx et le journal des erreurs. Il n'y a pas de journal pour les appels ayant échoué.
Nous avons le même problème ici avec Nginx 1.10.0 (et 1.9.15), iOS 9.3.1 utilisant HTTP/2 avec TLS 1.2.
Le problème disparaît avec HTTP/1.1 et fonctionne également avec HTTP/2 dans la version Nginx à la version 1.9.14.
Nginx 1.11.0 Mainline est maintenant disponible avec le correctif inclus mentionné plus haut dans cette rubrique;
Modification: les clients HTTP/2 peuvent maintenant commencer à envoyer le corps de la demande immédiatement; la directive "http2_body_preread_size" contrôle la taille de la mémoire tampon utilisée avant nginx commencera à lire le corps de la requête du client.
Je l'ai testé et pour moi cette version fonctionne à nouveau correctement.
Cela ressemble à un bogue confirmé dans nginx 1.10. Un problème à ce sujet se trouve sur le gestionnaire de bogues de nginx à l’adresse https://trac.nginx.org/nginx/ticket/979 Le numéro réel peut être trouvé à https://trac.nginx.org/nginx/ticket/959
Vous voudrez peut-être envisager de passer à la branche 1.9 qui contient des versions qui fonctionnent. Espérons que nginx publiera bientôt une version 1.10.1 qui n’a pas ce bogue.
En réalité, le problème ne se produit que sur iOS. Android, Windows et OSX ne semblent pas rencontrer de problèmes pour négocier une connexion http2 valide.
Je peux également confirmer que le nginx 1.9.15 ne fonctionne pas correctement. Certains appels ont toujours reçu "Impossible de se connecter au serveur", et après le retour à nginx 1.9.12, tout fonctionne correctement.
Ce sont les étapes que je voudrais essayer de suivre:
3) configurez un gestionnaire alamofire et modifiez le délai (pour cette étape, écrivez du code):
var alamofireManager = Alamofire.Manager.sharedInstance
let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
configuration.HTTPMaximumConnectionsPerHost = 10
configuration.timeoutIntervalForRequest = 30
configuration.timeoutIntervalForResource = 30
alamofireManager.delegate.taskWillPerformHTTPRedirection = nil
(Pour cette dernière étape, les prochains appels alamofire peuvent être par exemple: alamofireManager.request(etc....
)
Problème résolu!!!
versions:
1. Nginx version: 1.10.2
2. IOS version: 9.3.2
Quand la config aime ça:
listen 443 ssl;
J'ai le même problème que toi.
Mais !!!
Quand la config aime ça:
listen 443 ssl http2;
Problème résolu!!