Discussion :

[Lung]

Depuis quelques jours, l'appel à un webservice externe ne fonctionne plus.
On obtient "HTTP/1.1 400 Bad Request" et rien d'autre.

C'est un simple appel en GET (https://urlenquestion/CARD/12345789) avec un jeton en "Authorization".
Le jeton est préalablement obtenu avec un appel d'une autre fonction en POST qui fonctionne toujours. Donc, on arrive toujours à attaquer le webservice.

Ce qui fonctionnait jusqu'à il y a quelques jours :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
IdIOHandler.SSLOptions.SSLVersions := [sslvTLSv1_2];
IdHttp.IOHandler := IdIOHandler;
 
IdHTTP.Request.Accept := 'application/json';
IdHttp.Request.ContentType := 'application/json';
IdHttp.Request.CustomHeaders.Values['Authorization'] := 'Bearer ' + sJeton;   // << chaine qui contient le jeton préalablement récupéré.
IdHttp.Request.CharSet := 'UTF-8';
 
IdHttp.Get(TIdURI.UrlEncode(sURL + sRequete), Reponse);

Par contre, avec postman (et arc), l'appel fonctionne toujours.
Le jeton est paramétré comme ça :


Sachant que :
- l'application cliente en delphi 2007 n'a pas changé.
- le webservice n'aurait pas été modifié. J'ai cru comprendre qu'il est hébergé sur azure.
- le certificat est toujours valide.

J'ai essayé de comparer les propriétés du style ("Content-Type", "Accept", ...) mais je ne vois pas ce qui pourrait soudain causer le pb.
Si quelqu'un a une piste à explorer, je suis preneur ...

[Paul TOTH]

peut-être sslvTLSv1_2 avec un serveur qui serait passé en TLS 1.3 ?

tu peux tester avec Indy SChannel qui supporte TLS 1.3

https://github.com/tothpaul/Delphi/t.../Indy.SChannel

[Lung]

peut-être sslvTLSv1_2 avec un serveur qui serait passé en TLS 1.3 ?

Le serveur acceptait même TLS 1.0 (parait-il). Donc, le pb ne devrait pas être là.

J'ai un collègue qui a trouvé ce qu'il fallait ajouter pour que ça remarche comme avant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
      IdHttp.Request.CustomHeaders.FoldLines := False;      // << La ligne magique qui change tout.
      IdHttp.Request.CustomHeaders.Values['Authorization'] := 'Bearer ' + sJeton;

Donc à priori, pb résolu.
Si quelqu'un connait la signification de cette ligne (histoire de m'instruire ), ça m'intéresse ...


Sinon, autre info :
J'avais testé d'extraire le code d'interrogation du webservice pour le mettre dans un projet de test en D10.3 (rigoureusement le même code).
Et ça fonctionnait bien (sans la nouvelle ligne).

[Paul TOTH]

je suppose que c'est le fait de spliter les lignes trop longues...peut-être que ton jeton est mal découpé et arrive incorrectement au serveur.

[ShaiLeTroll]

FoldLines c'est un truc pour les vieux serveurs avec Indy 9, c'est pour mettre sur plusieurs lignes si l'entête est trop long qui dépasse FoldLength qui est défini à 78 + CRLF, oui la bonne vieille limite de 80 colonnes
Sauf qu'avec Indy 10, FoldLines est ne devrait pas avoir d'impact en HTTP,
normalement, cela ne devrait pas avoir d'effet puis que FoldLength a une valeur infinie en HTTP, c'est une valeur pour MIME à 78 (RFC 2045) ou encore plus vieux le RFC 822

Du coup, sur le jeton, cela doit ajouter un retour à la ligne, peut-être même un espace pour indiquer un entête sur plusieurs lignes qui est supporté par MIME mais pas par HTTP

le sJeton est bien une chaine Base64, parce que Indy se base un peu trop souvent sur des astuces de caractères de substitution qui font bien déconner ce genre de code d'alignement

Je l'ai eu récemment sur des . tout seul sur ligne dans un corps de mail récupéré via GRAPH et lu via un TIdMessage qui lui s'attend à échappement en .. si ce n'est pas la vraie fin du mail, ce qui fait le TIdPOP3, TIdIMAP4 ... et que j'ai du reprendre en GRAPH MAIL.