web-dev-qa-db-fra.com

Domaine d'erreur = Code NSPOSIXErrorDomain = 100 "Erreur de protocole"

J'essaie d'appeler un service en utilisant Alamofire en utilisant une méthode .get . La demande n'a rien de spécial, ni de paramètres, mais juste un en-tête d'autorisation.

Je suis un peu en colère parce que demander fonctionne bien lorsque je l'exécute sur postman avec la même adresse URL et le même jeton d'autorisation, mais lorsque j'exécute mon code d'application avec Alamofire, cette erreur renvoie l'erreur:

Domaine d'erreur = Code NSPOSIXErrorDomain = 100 "Erreur de protocole" UserInfo = {NSErrorPeerAddressKey = {longueur = 16, capacité = 16, octets = 0x100201bbd83ad0b10000000000000000}, _kCFStreamErrorCodeKey = 100, _kCFStreamDromeDomainKey}.

J'utilise:

Alamofire.request("https://myserverURL", method: .get, parameters: [:], encoding: JSONEncoding.default, headers: ["Authorization":"myToken"])
        .responseJSON {response in 

    guard response.result.error == nil else { 
       //HERE IS WHERE IS GOING IN WITH THE ERROR
    }
}

Toute pensée sera très appréciée ou me dirigera dans la bonne direction :)

iosswiftalamofire
10
LuchoG

J'ai eu exactement la même erreur que la tienne dans Cocoa avec la classe de fondation URLSession. Après des heures de débogage, le problème réside dans le corps de la requête HTTP.

Vous devriez vraiment essayer de vider le corps de requête/réponse HTTP pour voir s’il existe des champs mal formés. Par exemple, Content-Length et Content-Type sont corrects ou manquants? D'après mon expérience, si ces en-têtes (fondamentaux) requis sont mal formés, il est possible que ne fonctionne pas en fonction de votre système d'exploitation ou de tout autre réseau intermédiaire accepté (proxy, passerelle, serveur, etc.).

Mon erreur est de placer des paramètres de fonction dans la méthode URLRequest.addValue("application/x-www-form-urlencoded", forHTTPHeaderField: "Content-Type"), ce qui aboutit à un champ HTTP Content-Type incorrect.

Cependant, cela fonctionne dans macOS 10.12 mais pas 12.11, donc vous devez vous assurer que le corps de votre requête HTTP n’est pas mal formé.

J'espère que ça aide.

Former votre exemple de code, je suppose que le encoding: JSONEncoding.default est faux. Comme une méthode HTTP GET n'a AUCUN corps, un composant réseau strict/non-robuste le rejetterait/ne le comprendrait pas.

Quel est votre objectif? Définissez Accept: application/json dans l'en-tête de la requête. Toutefois, cela n'est pas obligatoire si vous êtes certain du type de corps de la réponse.

6
longkai

J'ai eu cette erreur avec Apache en envoyant un en-tête upgrade. Voici un lien vers la discussion bugzilla d'Apache sur le sujet.

Corrigé en ajoutant Header unset Upgrade à la configuration de l'hôte dans Apache.

4
boidkan

C'était un problème au moins pour moi pendant toute une journée ???? Je trouve à la fin comment le résoudre, c’était un problème de version de protocole HTTP avec le serveur. 

Nous utilisions IIS pour vous connecter à une API de développement et par défaut IIS si je me souviens bien, utilisez HTTP 2.0 si le client et le serveur le prennent en charge. De plus, notre serveur utilisait un certificat SSL pour l’API de développement, je pense donc que c’était là le problème principal associé à HTTP 2.0. La désactivation de l'utilisation de HTTP 2.0 pour IIS dans l'API de développement corrige le problème.

Mon conseil est donc d'essayer de surveiller la demande entrante pour voir quel type de protocole utilise la demande sur le serveur. Vous pouvez le faire avec Charles ou tout autre outil de surveillance HTTP. 

J'espère que cela aide quelqu'un d'autre avec le même problème. 

3
Victor Sigler

essayez de remplacer ces paramètres: [:] par des paramètres: nil dans votre requête. Étrangement, cela a résolu le problème.

2
Giggs

L'ajout de ["Content-Type": "application/json"] aux en-têtes a aidé.

1
Eduardo Victorino M C

J'ai eu le même problème résolu en remplaçant Authorization feild value to nil au lieu de ""

[request setValue: @"" forHTTPHeaderField:@"Authorization"];

changé pour cela

[request setValue: nil forHTTPHeaderField:@"Authorization"];
0
Sh_Khan

Si vous utilisez une sorte de renifleur, essayez de le désactiver. Courir Charles était la raison de cette erreur pour moi. Je téléchargeais des fichiers sur le serveur, et cela ne fonctionnait que pour de petits fichiers (plusieurs ko). Un fichier de 500 Ko me conduit à un échec "EOF" sous Charles et à votre erreur sous xCode. Désactiver Charles permettait de télécharger n’importe quel fichier volumineux. Je n'ai pas encore trouvé la raison exacte de cela. Charles a bien travaillé avec la même requête via Web, mais pas avec iOS.

0
surfrider

Dans mon cas, il y avait plusieurs équilibreurs F5 dans le réseau de test. Un des serveurs F5 validait la requête de manière incorrecte, de sorte que les objets de JSON contenant @ ou/étaient considérés comme malformés. Le problème était difficile à détecter, car il a souvent fonctionné pour moi, mais rarement, exactement selon le serveur F5 mal configuré spécifique avec lequel mon application client communiquait.

0
Vladimír Slavík