cf. Erreur HTTP 413 lors de l'upload d'un fichier
Au niveau applicatif = au niveau du socle Simplicité, la limite d’upload est livrée, par défaut, à 100 (= 100Mb), vous pouvez la modifier à la hausse ou à la baisse si besoin via le paramètre système MAX_UPLOAD_SIZE.
Si vous utilisez le Tomcat préconfiguré qu’on utilise sur nos serveur cloud (SIM) et qu’on package dans nos images Docker et les archives tar.gz downloadables, il n’y a pas de limite d’upload positionnée par défaut à ce niveau (maxPostSize="-1"), vous pouvez jouer sur cet attribut Tomcat en positionnant explicitement la variable d’environnement TOMCAT_MAXPOSTSIZE.
Bref, si vous n’avez rien configuré explicitement ni au niveau Tomcat ni au niveau Simplicité et que vous expérimentez une limite d’upload pour un fichier de taille < 100Mb c’est nécessairement que cette limite est imposée par un composant en amont de Tomcat : reverse proxy, equipement réseau, etc. ou par le navigateur.
PS: s’agissant d’importer un module, il existe d’autres approches plus “industrielles” que de faire l’import manuellement via la UI :
- appel
curlsur le endpoint I/O ad hoc (cf. I/O services service =moduleimport), typiquement si vous l’appelez “en local” directement sur Tomcat vous ne serez pas limité par un éventuel élément réseau externe - utilisation de la mécanique d’import spec (cf. Import spec : c’est décrit ici dans un doc relatif à Docker mais ce mécanisme n’est pas spécifique à ce mode de déploiement)
- utilisation de la mécanique Git des modules
L’import manuel de modules ou autre via la UI est pratique en dev/test mais n’est pas un mécanisme “industriel” pour la prod