[Android][REST] [Posgresql] Le caractère fantôme!

Version imprimable

Bonjour à tous,

Je ne suis pas sûr du bon classement du sujet... Je laisserai le cas échéant le soin aux responsables de le déplacer sous un répertoire plus concerné le cas échéant. Merci d'avance.

J'ai une app pour Android qui appelle une fonction disponible dans une base de données postgresql via REST en lui transmettant des paramètres
Code:

1 2 3 RESTRequest1.Resource:='{Nom de la fonction}'; RESTRequest1.Params.AddItem('{Nom du paramètre}',{Valeur transmise sous forme de string}, TRESTRequestParameterKind.pkGETorPOST,[TRESTRequestParameterOption.poDoNotEncode]);
Et là, on fait dans la magie...

Pour un paramètre entrant de la fonction de la DB déclaré de type "text" ou "Varchar, si la valeur transmise commence par un caractère alphabétique, cela fonctionne: "Toto" est récupéré au niveau de la fonction comme "Toto"

Mais si la valeur transmise commence par un chiffre, la valeur récupérée est affublée d'un caractère indésirable: "10Toto" devient par exemple"'10Toto" (Oui, oui, regardez bien, il y a un caractère apostrophe qui est apparu en 1ère position mais cela peut être un autre caractère :koi: )

J'ai compilé avec Delphi 10.3: Impossible de transférer correctement une valeur commençant par un caractère numérique.

Est-ce que quelqu'un a déjà constaté ce comportement?
Est-ce un bug connu?
Y-a-t-il une solution autre que de toujours commencer l'envoi d'une valeur numérique par un caractère alphabétique qu'il va falloir ensuite supprimer au niveau de la fonction pour récupérer les caractères numériques?

30/11/2022, 14h20
ShaiLeTroll

Question quel est le rapport en REST et PostgreSQL évoqué dans le titre ?
Au final, l'application cliente Android n'a pas d'accès à PostgreSQL, c'est un n-tiers classique avec un middleware REST ?
Autant retirer de l'équation les informations inutiles.
Car c'est confus, on a du mal à comprendre où apparaît le ' !

Pourquoi ne pas faire un programme simple, juste en dur des valeurs envoyées par REST
Idem, un mini serveur de test
Sans tout lien avec la base de données pour reproduire l'anomalie.

J'utilise plutôt AddParameter que Params.AddItem, cela ne change pas grand chose, juste que AddParameter efface et recréee la valeur\type si le paramètre avec ce nom existe déjà alors que AddItem va plutôt mettre à jour l'existant, faudrait voir si cela peut avoir un impact.

Déjà est-ce la partie cliente qui ajoute le '
Ou est-ce la partie serveur qui ajoute le ' ?
Avez-vous vérifier le contenu émis par le client et reçu par le serveur ? ainsi que l'URL en GET (ou POST) de la forme Param=Valeur&Param=Valeur
Pensez que vous pouvez aussi soumettre un JSON pour par exemple gérer des tableaux de données à injecter en base.

'10Toto' n'est pas une valeur numérique mais alphanumérique, cela doit être traité comme n'importe quel autre texte.

Un Server TCP IP vite fait avec TIdTCPServer permet de voir facilement ce que l'on reçoit brut !

Code:

1
2
3
4
5
6
7
8
9
10
11
[SERVER] - 2022-11-30 14:57:52: Client Connected!
[SERVER] - 2022-11-30 14:57:52: Port=20010 (PeerIP=127.0.0.1 - PeerPort=56717)
[CLIENT] - 2022-11-30 14:57:52: (Peer=127.0.0.1:56717) Message GET /api/rest/function?S=10Toto HTTP/1.1
Connection: Keep-Alive
Accept: application/json, text/plain; q=0.9, text/html;q=0.8,
Accept-Charset: UTF-8, *;q=0.8
User-Agent: Embarcadero RESTClient/1.0
Host: localhost:20010
 
 
[SERVER] - 2022-11-30 14:57:52: Client Disconnected! Peer=127.0.0.1:56717

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
procedure TForm1.Button1Click(Sender: TObject);
var
  VClient: TRESTClient;
begin
  VClient := TRESTClient.Create('http://localhost:20010/api/rest/');
  try
    VClient.ContentType := 'application/x-www-form-urlencoded';
 
    with TRESTRequest.Create(VClient) do // The Client owns the Request (will free it) and it will assign as Client property
    begin
      Method := TRESTRequestMethod.rmGet;
      Resource := 'function';
 
      AddParameter('S', '10Toto', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]);
      Execute();
 
    end;
  finally
    VClient.Free();
  end;
end;

Changer ce détail comme le Verbe :

Code:

Method := TRESTRequestMethod.rmPOST;

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
[SERVER] - 2022-11-30 15:00:59: Client Connected!
[SERVER] - 2022-11-30 15:00:59: Port=20010 (PeerIP=127.0.0.1 - PeerPort=56781)
[CLIENT] - 2022-11-30 15:00:59: (Peer=127.0.0.1:56781) Message POST /api/rest/function HTTP/1.1
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Accept: application/json, text/plain; q=0.9, text/html;q=0.8,
Accept-Charset: UTF-8, *;q=0.8
User-Agent: Embarcadero RESTClient/1.0
Content-Length: 8
Host: localhost:20010
 
S=10Toto
[SERVER] - 2022-11-30 15:00:59: Client Disconnected! Peer=127.0.0.1:56781

En général pour un service REST
GET c'est tout sur l'URL
POST c'est la route sur l'URL par exemple un ID et dans le POST c'est un JSON

30/11/2022, 16h55
Anselme45

Citation:

Envoyé par ShaiLeTroll

Question quel est le rapport en REST et PostgreSQL évoqué dans le titre ?
Au final, l'application cliente Android n'a pas d'accès à PostgreSQL, c'est un n-tiers classique avec un middleware REST ?
Autant retirer de l'équation les informations inutiles.

C'est clairement un bug soit au niveau du client REST (côté Delphi), soit au niveau du serveur REST (et là, c'est PostgREST, la couche REST de Postgresql). Désolé, je ne considère dès lors pas qu'il y a ici information inutile!

Citation:

Envoyé par ShaiLeTroll

Car c'est confus, on a du mal à comprendre où apparaît le ' !

La fonction qui se trouve dans posgresql reçoit comme paramètre d'entrée des chiffres précédés d'un apostrophe ou autre caractère-non voulu alors que le code Delphi n'envoie que des chiffres.

Citation:

Envoyé par ShaiLeTroll

Pourquoi ne pas faire un programme simple, juste en dur des valeurs envoyées par REST
Idem, un mini serveur de test
Sans tout lien avec la base de données pour reproduire l'anomalie.

Déjà fait!!! J'envoie harcodés "10Toto" et la fonction dans Postgresql reçoit "'10Toto" (la valeur de départ précédée de l'apostrophe). Si j'envoie "Toto" non précédé de chiffre, postgreql reçoit la bonne valeur sans l'ajout de l'apostrophe. Idem si la valeur envoyée est "Toto10", la bonne valeur est reçue dans la DB.

Citation:

Envoyé par ShaiLeTroll

Déjà est-ce la partie cliente qui ajoute le '
Ou est-ce la partie serveur qui ajoute le ' ?
Avez-vous vérifier le contenu émis par le client et reçu par le serveur ? ainsi que l'URL en GET (ou POST) de la forme Param=Valeur&Param=Valeur
Pensez que vous pouvez aussi soumettre un JSON pour par exemple gérer des tableaux de données à injecter en base.

'10Toto' n'est pas une valeur numérique mais alphanumérique, cela doit être traité comme n'importe quel autre texte.

Vu que le paramètre attendu par la fonction est du texte, "1234", "Toto" ou "10Toto" devraient tous être considérés comme du texte et dans les faits, ils le sont! Ce n'est pas là que se situe le problème mais lorsque le 1er caractère du texte transmis est un caractère représentant un chiffre de 0 à 9. Dans ce cas, la valeur récupérée dans la DB est précédée d'un caractère supplémentaire qui apparait au début du texte envoyé.

Après avoir développé une application Client REST de test avec un autre IDE que Delphi Rio 10.3.3, il s'avère que le problème n'apparait pas.

Donc, tout porte à croire que le problème a pour origine le client REST de Delphi 10.3.3

Après avoir appliqué tous les packs de mise à jour de Delphi 10.4, il semble que le problème n'apparait plus si le projet est compilé non pas avec Delphi 10.3 mais avec Delphi 10.4

Je vais faire des tests plus poussés avant d'indiquer le cas comme résolu, mais je crois que la solution est trouvée.

Merci encore pour le coup de main... C'est précieux!
30/11/2022, 17h29
ShaiLeTroll

C'est déjà plus clair, c'est PostgreSQL qui fourni le Server REST, comprenez que l'on ne pouvait pas le deviner cela pouvait être un programme Delphi qui faisait le bridge.

J'indique que j'ai testé en D10.0 ... au moins le bug est limité à une petite release :roll:
01/12/2022, 11h54
Anselme45
J'ai bien fait de pousser plus loin mes tests.

1. Il n'y a pas de différence de comportement entre une app compilée en Delphi 10.3 ou 10.4

2. Ce n'est pas un bug à proprement parlé mais un comportement voulu du client REST de Delphi

3. Un texte envoyé via REST n'est pas envoyé tel quel, il est modifié selon des règles précises:
- Si on veut envoyé un texte "Salut%60327", le texte reçu par le serveur REST sera "Salut'327" > En fait, le %60 est remplacé par le caractère apostrophe dont le code ASCII est... 60!
- Si on veut envoyer un texte "Salut+60327", le texte reçu par le serveur REST sera "Salut 60327" > Le caractère + est remplacé par un espace!
- Si on veut envoyer un texte "Salut%c3%a160327", le texte reçu par le serveur REST sera "Salut{a avec un accent aigu}60327" > Le caractère {a avec accent aigu} est codé en UTF8 sur 2 bytes c3 et a1!
Dès lors apparaissent d'autres questions...

Est-il possible de désactiver ce comportement (Dans la requête REST, il est pourtant précisé [TRESTRequestParameterOption.poDoNotEncode])?

Sinon, est-ce que quelqu'un sait où trouver une définition exhaustive du mode de fonctionnement de ce processus de modification du texte d'origine? On comprend que le % permet de coder un caractère à l'aide de son code ASCII (utile peut-être pour les caractères exotiques (Quoi que, puisque Delphi permet de saisir dans le texte d'origine des caractères exotiques qui seront transmis tels quels au serveur REST sans passer par le codage ASCII), mais le cas du + qui se transforme en espace laisse penser qu'il y a peut-être d'autres caractères qui entraînent des modifications du texte original.

Curieusement, j'ai l'impression que tu vois le problème à l'envers
pour moi c'est le Serveur qui reçoit qui décode ce tu as envoyé en Delphi en brut
Encore une fois en vérifiant à une serveur TCP IP Brut, on voit la donnée brute sans l'interprétation du receveur

Et que le receveur décode ce qui est URL \ URI encoded est tout à fait normal, c'est un mécanisme automatique, Delphi fait de même lorsqu'il reçoit, ça évite de le faire soit même.

Avec TRESTRequestParameterOption.poDoNotEncode

Method := TRESTRequestMethod.rmGET;

AddParameter('S', 'Salut%60327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); -> [CLIENT] - 2022-12-01 15:53:15: (Peer=127.0.0.1:64313) Message GET /api/rest/function?S=Salut%60327 HTTP/1.1

AddParameter('S', 'Salut+60327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); -> [CLIENT] - 2022-12-01 15:54:27: (Peer=127.0.0.1:64319) Message GET /api/rest/function?S=Salut+60327 HTTP/1.1

AddParameter('S', 'Salut%c3%a160327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); -> [CLIENT] - 2022-12-01 15:55:04: (Peer=127.0.0.1:64323) Message GET /api/rest/function?S=Salut%c3%a160327 HTTP/1.1

Method := TRESTRequestMethod.rmPOST;
Code:

1 2 3 4 AddParameter('S1', '10Toto', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); AddParameter('S2', 'Salut%60327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); AddParameter('S3', 'Salut+60327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]); AddParameter('S4', 'Salut%c3%a160327', TRESTRequestParameterKind.pkGETorPOST, [TRESTRequestParameterOption.poDoNotEncode]);
->
Code:

1 2 3 4 [CLIENT] - 2022-12-01 16:20:52: (Peer=127.0.0.1:64487) Message POST /api/rest/function HTTP/1.1 Content-Length: 59 S1=10Toto&S2=Salut%60327&S3=Salut+60327&S4=Salut%c3%a160327
Sans TRESTRequestParameterOption.poDoNotEncode
Code:

1 2 3 4 AddParameter('S1', '10Toto', TRESTRequestParameterKind.pkGETorPOST, []); AddParameter('S2', 'Salut%60327', TRESTRequestParameterKind.pkGETorPOST, []); AddParameter('S3', 'Salut+60327', TRESTRequestParameterKind.pkGETorPOST, []); // le + est le seul ré-encodé dans les exemples ci-présents AddParameter('S4', 'Salut%c3%a160327', TRESTRequestParameterKind.pkGETorPOST, []); // le % est différement encodé selon GET ou POST ? WTF ?
Method := TRESTRequestMethod.rmGET;

Code:

[CLIENT] - 2022-12-01 16:01:05: (Peer=127.0.0.1:64359) Message GET /api/rest/function?S1=10Toto&S2=Salut%60327&S3=Salut%2B60327&S4=Salut%c3%a160327 HTTP/1.1

System.Net.URLClient.TURI.URLEncode autorise 'A' .. 'Z', 'a' .. 'z', '0' .. '9', '-', '_', '.', '~'
Mais considère que si l'on a mis dans la chaine %FF c'est que l'on a encodé soit même la chaine donc il conserve cela ! :aie::ptdr::weird::fou::lefou::wow::traine::traine::traine::traine:

Method := TRESTRequestMethod.rmPOST;
Code:

1 2 3 4 [CLIENT] - 2022-12-01 16:16:05: (Peer=127.0.0.1:64465) Message POST /api/rest/function HTTP/1.1 Content-Length: 67 S1=10Toto&S2=Salut%2560327&S3=Salut%2B60327&S4=Salut%25c3%25a160327
+ et % ne sont pas dans la liste des caractères autorisés : 'A' .. 'Z', 'a' .. 'z', '0' .. '9', '-', '_', '.', '~' voir REST.Utils.URIEncode qui ne conserve pas les %FF donc qui le ré-encode un coup, ce qui me semble pas plus mal, c'est plus simple !

Perso, le System.Net.URLClient.TURI.URLEncode qui considère les %FF comme déjà encode, je suis trouve cela un peu vicieux si l'on voulait envoyer volontairement des séquence %FF%FF%FF
Oui poDoNotEncode est là pour que l'on puisse le faire mais cela implique si l'on mélange du %FF avec autre chose de devoir refaire l'encodage soit même de la partie "autre chose"

Voir si 10.4 utilise à la place System.NetEncoding.TNetEncoding.URL comme recommandé !
Je suis en 10.0 donc le code peut être différent, si TURI.URLEncode est maintenant déprécié, cela ne me surprend pas, c'est une mauvaise fonction
Code:

1 2 3 Display('System.NetEncoding.TNetEncoding.URL.Encode(Salut%c3%a160327)',System.NetEncoding.TNetEncoding.URL.Encode('Salut%c3%a160327')); Display('REST.Utils.URIEncode(Salut%c3%a160327)', REST.Utils.URIEncode('Salut%c3%a160327')); Display('System.Net.URLClient.TURI.URLEncode(Salut%c3%a160327)', System.Net.URLClient.TURI.URLEncode('Salut%c3%a160327')); // tordu et piégeux en D10.0 donc GET foireux pour envoyer %FF%FF%FF sans qu'il considère cela comme déjà encodé
Code:

1 2 3 [System.NetEncoding.TNetEncoding.URL.Encode(Salut%c3%a160327)] - 2022-12-01 16:35:23: Salut%25c3%25a160327 [REST.Utils.URIEncode(Salut%c3%a160327)] - 2022-12-01 16:35:23: Salut%25c3%25a160327 [System.Net.URLClient.TURI.URLEncode(Salut%c3%a160327)] - 2022-12-01 16:35:43: Salut%c3%a160327