FAQ n°20558, publiée le 06/06/2017, mise à jour le 19/09/2023
Consommation d'un webservice, requête https, AuthIdentifie, API REST, comment traiter le retour "100138, erreur détectée pendant l'envoi de la requête HTTP" ?

Lorsqu'une requête en HTTPS est envoyée pour exécuter une page d'un site, appeler une API REST, consommer un webservice SOAP, s'authentifier avec AuthIdentifie, la requête peut échouer avec le retour suivant du mécanisme de sécurité du WLangage :  


Fonction 'HTTPEnvoie' ou 'RestEnvoie'

Une erreur système a été détectée pendant l'envoi de la requête HTTP.

Code erreur : 100138

Niveau : erreur non fatale


Ce retour apparaît si le chiffrement de la connexion entre le poste qui lance la requête HTTPS et le serveur n'est pas possible. L'échec du chiffrement peut être lié :

  • à la requête,
  • à la configuration du poste à l'origine de l'envoi,
  • à la configuration du serveur contacté, ou de son certificat...


Afin de permettre l'appel, il faut effectuer les vérifications suivantes : 

  • Contrôler l'URL donnée, elle ne doit pas contenir d'espace ou de caractère non conforme aux URL.

  • Si la requête est envoyée avec une variable httpRequete/restRequête, vérifier que dans les entêtes données à la variable httpRequete/restRequête il n'y a pas ["accept-encoding"].

  • Vérifier que la station à l'origine de l'appel :
    • est à jour de Windows Update, et de ses réglages de sécurité.

    • dispose au minimum de TLS 1.2 (cf. FAQ 24866) . Cette version est maintenant la version minimale imposée par les serveurs qui hébergent des sites et webservices s'ils sont sûrs. SSL 2.0 minimum est également un prérequis.

    • dispose des bases de données de certificats à jour : 
      • copier dans le navigateur Internet Explorer ou Edge l'url complète qui ne peut pas être appelée par programmation. Cela peut suffire à forcer le système à récupérer les données manquantes pour valider le certificat.

      • si la requête échoue encore, exécuter cette requête avec la fonction WLangage HTTPrequete, à la place de la fonction HTTPEnvoie. La fonction HTTPrequete force la mise à jour des certificats racines. Il est ensuite possible d'utiliser HTTPEnvoie.
        Ce point est valable pour toutes les versions jusqu'à la version 25 incluse. A partir de la version 26, la fonction  HTTPEnvoie sait également forcer la mise à jour comme la fonction HTTPrequete.

      • si la requête échoue encore, s'il s'agit d'un certificat qui n'est pas émis par une autorité de confiance, il est possible de forcer sa reconnaissance :
  • Contrôler les versions du protocole HTTP supportées par le serveur contacté. A partir de la version 26, HTTP 2.0 est utilisé par défaut. Si le serveur ne supporte pas cette version, une version plus ancienne est automatiquement sélectionnée. Mais il peut arriver qu'un serveur indique gérer HTTP 2.0, sans respecter toutes les spécifications de cette version du protocole.
    Dans pareil cas, il est possible de forcer l'utilisation d'une version de HTTP adaptée au serveur avec la propriété ..VersionHTTP de la variable RestRequete ou httpRequete


Cas particuliers :

  • si la station à l'origine de l'appel ne peut pas disposer de TLS 1.2, mais que le serveur à contacter l'impose, et que l'appel est fait avec la fonction HTTPRequete, il peut être possible d'exécuter la requête :
  • si la station à l'origine de l'appel ne peut pas disposer de TLS 1.2, mais que le serveur à contacter l'impose, et que l'appel est fait avec la fonction AuthIdentifie, l'authentification peut être possible en la précédent de l'appel suivant : 
    HTTPParamètre( HttpParamètreMode, 2)

    Dans ces deux cas, il est vivement recommandé d'effectuer les changements nécessaires sur la station pour lui permettre d'avoir TLS 1.2.

  • en version 28 grâce à l'augmentation de la sécurité avec OpenSSL3, certaines requêtes HTTPS peuvent échouer avec ce retour depuis iOS. Ce cas est détaillé dans la FAQ 24198 :
    https://faq.pcsoft.fr/24198-faq-read.awp