- Statut changé de Feedback à In progress...
Bon, j'ai demandé à Claude au cas où. Apparemment, il y a bien eu une régression en 6.4.7 avec les corrections de vulnérabilités :
Ce qui a changé en 6.4.7¶
Avant 6.4.7, le JS envoyait X-FULL-PATH: encodeURIComponent(file.fullPath) . L'en-tête ne contenait donc que de l'ASCII, et le serveur faisait URLDecoder.decode(..., UTF-8) dans FileUploadData.from() .
Le commit eaf1608a8a (vulnérabilité #15358) a remplacé ce décodage par Encode.forHtml() côté serveur, ce qui a cassé les noms encodés. C'est la régression #15388.
Le commit 1113f19f3d (correction de #15388) a alors supprimé l'encodage URI côté client. Le JS envoie maintenant le nom brut avec un simple escapeHTML() dans l'en-tête, voir core-war/src/main/webapp/util/javaScript/silverpeas-ddUpload.js:584 et _ silverpeas-fileUpload.js:759_ . Le serveur ne fait plus que StringUtil.normalize() (NFC).
Pourquoi ça ne casse que sur Mac OS¶
Un en-tête HTTP est une chaîne ISO-8859-1. XMLHttpRequest.setRequestHeader() lève une exception dès que la valeur contient un caractère au-delà de U+00FF : TypeError: Failed to execute 'setRequestHeader' on 'XMLHttpRequest': String contains non ISO-8859-1 code point.
Sur Windows et Linux, les noms de fichiers sont en forme NFC : « é » est le seul code point U+00E9, qui passe. Sur Mac OS, le système de fichiers fournit les noms en forme NFD : « é » devient « e » suivi de l'accent combinant U+0301. Ce code point dépasse U+00FF, donc l'exception est levée avant l'envoi. La requête ne part jamais et la publication n'est pas créée. C'est le premier symptôme.
Le second symptôme, l'encodage incorrect, vient du même mécanisme. Quand le nom passe quand même, il est transmis en octets Latin-1 bruts dans l'en-tête, et le décodage côté serveur dépend de la manière dont Undertow interprète ces octets. Je n'ai pas pu vérifier ce point précis. Un test avec un nom contenant « œ » ou « € » devrait aussi échouer sur tous les OS, ce qui confirmerait le diagnostic.
Mis à jour par