Une partie multipart part sans le type que sa signature ne couvre pas¶
src/test/java/fr/univ_amu/iut/commun/api/SignatureS3DepotTest.javaContexte¶
Aucun dépôt connecté n'aboutissait depuis juillet 2026 : S3 refusait chaque archive en
SignatureDoesNotMatch. Le journal de Samuel du 14 septembre (2.193.0) a été le premier à en porter
la cause, depuis que #3469 a cessé de jeter le corps du refus.
Le serveur Vigie-Chiro signe l'URL d'une partie multipart sans Content-Type
(fichier_multipart_continue dans vigiechiro-api). Le client envoyait le type mime de l'archive. En
signature S3 v2, le type fait partie de la chaîne signée : les deux signatures ne pouvaient pas
coïncider. Le seuil multipart est de 5 Mo et une archive réelle pèse de 38 à 377 Mo, donc toutes
passaient par ce chemin. Les bancs, eux, restaient verts : le bouchon acceptait n'importe quelle
partie (voir l'ADR 4356).
Décision¶
TransportVigieChiro.deposerPartie n'envoie aucun Content-Type. Le client envoie exactement ce
que le serveur a signé, ni plus ni moins. Le dépôt d'un fichier en un seul bloc, lui, garde son type :
son URL est signée avec.
Ce que cette décision n'autorise pas¶
Elle n'autorise pas à « remettre le type par propreté ». Un PUT sans type ressemble à un oubli, et
c'est le correctif qu'un lecteur ferait de bonne foi. Il casserait tous les dépôts sans faire rougir
un seul banc à bouchon.
Conséquences¶
La règle dépend de ce que le serveur signe, pas de ce que S3 accepte : si vigiechiro-api change sa
signature, c'est ici qu'il faudra suivre. SignatureS3DepotTest recalcule la chaîne signée pour que
l'écart se voie sans réseau.