Erreur HTTP 413 module upload

Request description

Bonjour,

Notre équipe rencontre le problème suivante sur une instance simplicité hébergée sur un serveur client.

Nous avons consulté les sujets concernant cette erreur sur le forum, mais nous n’avons pas trouvé de solution.

Pouvez-vous nous guider svp ?

A l’import d’un module dépassant une certaine taille erreur d’upload

Steps to reproduce

This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:

  1. Dans le menu Module >Module : X
  2. Choisir un fichier zip ou xml
  3. Sauvegarder
    Une erreur 413 est générée sur le front.
    La variable max size :MAX_UPLOAD_SIZE= 100

Technical information

Simplicité logs

2023-10-20 15:27:59,659|SIMPLICITE|WARN||http://frparintres01.groupe.active:8080||WARN|system|com.simplicite.webapp.servlets.ui.DefaultServlet|service||Event: /events is not requested with websocket protocol. The request is ignored.

Détails du /health de la plateformev :

[Platform]
Status=OK
Version=5.3.16
BuiltOn=2023-09-29 15:24
Git=5.3/ada6e86492cace177cb57b570853c82fab936aab
Encoding=UTF-8
EndpointIP=10.105.30.31
EndpointURL=localhost:8080
TimeZone=GMT+02:00
SystemDate=2023-10-20 15:34:41

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=localhost
ActiveSessions=2
TotalUsers=3
EnabledUsers=1
LastLoginDate=2023-10-20 15:32:13

[Server]
ServerInfo=Apache Tomcat/9.0.80
ServerType=WEB
ServerActiveSessions=2
ServerSessionTimeout=30
CronStarted=true

[OS]
Name=Linux
Architecture=amd64
Version=4.18.0-477.27.1.el8_8.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=2977
DiskUsable=2977
DiskTotal=3062

[JavaVM]
Version=17.0.8
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.8+7-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=296650
HeapSize=557056
HeapMaxSize=1964032
TotalFreeSize=1703626

[Cache]
ObjectCache=646
ObjectCacheMax=10000
ObjectCacheRatio=6
ProcessCache=646
ProcessCacheMax=10000
ProcessCacheRatio=6
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=1
ProductName=HSQL Database Engine
ProductVersion=2.7.1
DriverName=HSQL Database Engine Driver
DriverVersion=2.7.1
DBDate=2023-10-20 15:34:41.802987+2:00
DBDateOffset=0
DBPatchLevel=5;P03;eae816e5089006449212ca1f2a1fc9f4
UsingBLOBs=false

[Healthcheck]
Date=2023-10-20 15:34:41
ElapsedTime=3

Merci d’avance.

Bonjour Thomas,

Un certain nombre de pistes avaient été suggérées afin d’essayer de résoudre le problème. Peux-tu nous présenter ce qui a été testé, et les différents résultats pour chacunes des pistes.

Merci

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 curl sur 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

Bonjour et merci pour vos réponses.

Nous avons essayé l’import module par l’interface et par curl, les deux sans succès.
L’import module par l’interface fonctionne pour un module de taille réduite (quelques ko, nous n’avons pas essayé toutes les tailles).

Nous utilisons bien le tomcat préconfiguré.
Je n’ai pas le détail de tout ce qui a été utilisé comme cela est géré avant tout par l’équipe d’infra.
Il faut donc que l’on voit concernant les autres élements que vous avez cité tel que le reverse proxy, ou les équipement réseau. Je remonte ces informations aux équipes concernées.

Quand vous dites “par curl” est-ce que vous passez par la même URL de base que la UI ?

Si oui ça signifie que vous passez par les mêmes composants réseau et que donc, forcément, les mêmes limites induites par les composants réseau s’appliquent…

Le bon test à faire c’est un appel curl local = sur http://localhost:8080/io, c’est à dire directement sur Tomcat depuis le serveur sur lequel il tourne.

Si ça se passe correctement ça confirmera alors que le pb se situe bien en amont de Tomcat.

Bonjour,
On a augmenté la taille d’upload pour nginx et tomcat.
ci-dessous la commande passé sur le serveur :

curl -u designer:******* --form service=zipimport --form file=/logiciel/ressources/rsce/tomcat/Ressources-2.1.0.zip localhost:8080/io
{“status”:“WARN”,“msg”:“Empty data”}

Je ne comprend pas bien ce que vous testez. Si vous tapez sur http://localhost:8080 ça signifie que vous vous ne passez pas par un reverse proxy nginx, donc changer sa configuration ne changera rien.

Pour le reste, cf. mes réponses précédentes:

  1. au niveau de Tomcat il n’y a, par défaut, aucun limite d’upload (maxPostSize="-1"). S’il y en a une c’est que vous l’avez explicitement positionnée d’une manière ou d’une autre, sans vos fichiers de configuration et/ou scripts de démarrage Tomcat on ne peut pas savoir…
  2. au niveau de la webapp Simplicité il y a, par défaut, une limite à 100Mb (param système MAX_UPLOAD_SIZE)

on a ajouté de taille pour l’upload par l’interface web.

et pour l’upload par curl, on a testé par localhost et localhost:8080 mais le problème persiste

Je ne comprends pas ce que ça signifie exactment, vous pouvez préciser ?

Test curl sur une instance Docker Simplicité 5.3 out of the box avec un export ZIP d’une resource image de ~11Mb:

La resource est bien chargée:

Etes vous sûr de bien tester avec un export ZIP correct (i.e. qui contient un XML et les fichiers des documents/images) ? ex:

Bonjour,

Nous utilisons le tomcat fourni sur votre site, nous n’utilisons pas le docker.
Nous lançons la commande curl en localhost, donc on ne devrait pas avoir de soucis de réseau.

Le zip est généré correctement, là dessus pas de problèmes.

L’upload semble maintenant fonctionner à l’aide du curl, cependant on constate que suite à la commande, des erreurs apparraissaent sur les logs simplicité, mais celles-ci n’ont pas l’air d’avoir d’impact fonctionnel sur l’application.

Par exemple:

script: ResProgramme
java.io.IOException: Empty document
at com.simplicite.util.tools.JavaTool.getJavaDocument(JavaTool.java:795)

ERROR Validation error: [ERR_REQUIRED:Destinataire#ERROR#notiGcCdId]

Ces erreurs ne sont pas présentes en temps normal (pour une version identique à celle déployée), et aussi elle disparraissent lorsque je vide le cache serveur manuellement. Peut-être faut-il vider le cache après un curl? si oui peut-on lancer une commande pour l’automatisation du processus ?

Finalement pour finir sur une bonne note, l’upload par l’interface fonctionne (plus d’erreur 413). L’équipe d’infra a du faire de bonnes manipulations pour permettre cela.

Merci encore pour votre aide

Bonjorur Thomas,

Tu devrais pouvoir accéder aux logs générés par l’import du module dans Exploitation > Supervision imports.
Si dans le fichier de logs il y a des erreurs, il faut corriger le module à la source afin de les éviter au prochain import.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.