Discussion :

[many6801]

Merci pour ta réponse rapide.
Mon collègue va mettre en place des logs sur le serveur.
De mon côté, quand je transmets un ZIP (Data.zip) contenant uniquement des fichiers .txt, cela fonctionne, on arrive à communiquer. (taille : 1109Ko)
Dans un deuxième temps, j'ajoute un autre ZIP (IMG.ZIP) à mon Data.zip.
Ce IMG.zip contient un fichier .JS et plusieurs dossiers contenant des imagettes PNG d'une taille de 66Ko chacune.
Après compression de tout ça, le fichier Data.zip atteint 9100Ko.
A ce moment là, ça ne passe plus.

A l'heure actuelle, j'essaye de réduire mon Data.zip en y incluant chaque dossier individuellement, pour voir à quel niveau ça pêche, mais pour le moment j'ai 'HTTP/1.1 500 Internal Server Error' donc je suis un peu bloquée.
Nous continuons les recherches, merci pour tes remarques pertinentes !

[many6801]

J'ai pu reprendre mes tests, l'erreur n'était que temporaire.
J'ai essayé d'envoyer mon Data.zip avec uniquement 3 dossiers sur 4 (contenant les imagettes), là, l'archive n'atteint que 6342Ko, ça passe.
Je l'ai montée à 7073Ko, ça passe.
C'est vraiment dès que l'on dépasse les 8Mo de données que ça ne passe plus.

Est-ce vraiment du côté serveur que ça se joue ? N'y a t-il pas d'autres paramètres du côté du IdHTTP que je pourrais modifier ?

[ShaiLeTroll]

Oui, 8Mo était je crois le plafond que j'avais eu aussi !
Idem, des petits DB ne générait pas de gros CSV zippé Base64 encodé et lorsque j'ai volontairement utilisé une grosse DB, j'arrivais vers 9Mo, cela ne passait plus !
Je ne me rappelle plus du nom de la variable Apache concernée, c'est une limite VOLONTAIRE sur le serveur pour éviter qu'un client sature le serveur !
C'est une protection ! Si il n'y avait pas de limite, il serait rapide de provoquer des "Deny of Service" par saturation

J'utilisais pour ma part TRemotable et THTTPRio, je n'ai absolument rien changé dedans !

[many6801]

Nous avons continué les tests.
J'étais prête à changer mon programme Delphi... Et mon collègue côté serveur a changé un paramètre :
php_value memory_limit 128M
Et depuis, ça passe...

On pense que c'est le dézippage qui utilise trop de mémoire vive au niveau du serveur, car nous avons des fichiers plats qui dépassent les 80Mo...

[ShaiLeTroll]

....une limite Apache, que l'on peut modifier, il y avait aussi une limite sur la taille mémoire du process PHP à 32Mo, le traitement étant lourd, j'ai poussé à 128Mo, ...

php_value memory_limit 128M

Son nom était pourtant simple, dingue, 3 ans après, j'ai oublié

N'oublie pas le bouton

Dans le projet dont je m'occupais, je ne crois pas que le zip qui était le coupable car je crois que le dev avait utiliser un fichier temporaire
Ce fichier temporaire étant ensuite charger par un LOAD de MySQL

le consommateur de RAM était le code PHP très complexe pour gérer l'import du fichier (un truc ultra parano aussi bien sur la structure que sur le contenu avec un tas de contrôle de cohérence des données)
En fait, cela pouvait générer plus de 100 erreurs par ligne de données, et il pouvait y avoir dans les 100 000 lignes, on avait ajouté un paramètre pour plafonner le nombre d'erreur (compris en 1 et 1000), surtout qu'ensuite fallait afficher les erreurs pour que l'utilisateur corrige ses données (un truc normalisé qui n'accepte que des données standardisées, avec un standard qui change tous les 2-3 ans, la correction ne pouvant pas être automatique à cause de la responsabilité métier liée aux données, on laissait l'utilisateur, un expert dans son domaine, pour effectuer les recodages, il avait la possibilité dans le logiciel de faire ça en masse évidemment)

[many6801]

Je ne poste une réponse finale que maintenant et m'en excuse.
Il s'avère qu'en changeant effectivement le paramètre : php_value memory_limit 128M, cela a résolu notre souci.
L'origine des problèmes est également dûe au fait que lorsque l'on encode en Base64 nos fichiers, leur taille augmente considérablement.
J'espère que mon problème servira à d'autres personnes en difficultés.
Je remercie ShailLeTroll pour son aide !
A bientôt.
Manon