AnsweredAssumed Answered

POST UTF-8 envoyé par IE brisé lorsque SSL est activé

Question asked by bouche64 on May 1, 2010
Latest reply on Aug 31, 2010 by bouche64
Bonjour j'ai un problème avec les paramètres des POST UTF-8 envoyé par IE6,7,8 lorsqu'on active le SSL (https)
Alfresco ne les décode pas correctement.
—–Tout d'abord voici comment celà se manifeste.

On inscrit un mot avec accent dans un des champs/formulaire qui font un POST. Dans l'exemple ci-dessous, un des champs de la recherche avancée.
[img]http://www.polymtl.ca/alfresco_bugs/utf8_1.jpg[/img]
Ci-dessous, on voit que la recherche avec le mot "éleve' n'a pas fonctionné, on remarque que la chaîne de caractères est réaffiché par Alfresco comme "Â@leve"
[img]http://www.polymtl.ca/alfresco_bugs/utf8_2.jpg[/img]

L'affichage de "Â@leve" représente le cas d'une chaîne de caractère en UTF-8 qui n'a pas été correctement décodée par l'application qui l'a traité comme du ISO8859-1. Le résultat est que le caractère en double bit (dans notre cas "é") est considéré comme 2 caractères.

Comme avec tout problème que je rencontre, je me pose toujours la question, est-ce un problème de config sur ma machine ou un problème présent systématiquement dans l'application. Donc, si quelqu'un a configuré en SSL et qu'il peut faire un simple test tel qu'expliqué ci-dessus et faire un constat en réponse à ce sujet ce serait très apprécié.

J'ai énormément cherché une solution à ce problème dans divers forums, j'ai trouvé un problème similaire (toujours avec IE) pour Cocoon et avec un serveur de mail qui fonctionnait en UTF-8 mais rien avec Alfresco et surtout aucune solution claire.

Pour ceux qui seraient curieux ou voudraient proposer des solutions, merci de lire ces quelques informations complémentaires:

Ma version d'Alfresco est community 3.2r2  sur RedHat, le TOMCAT est celui installé avec Alfresco par défault.

Le problème se manifeste SEULEMENT avec IE 6,7,8. Avec FireFox 3.x et autres fureteurs, c'est ok

IE affiche les écrans Alfresco comme du UTF-8 et envoi de l'UTF-8 au serveur.

Au départ le problème s'est manifesté via un reverse proxy  (avec mod_jk) qui s'occupait du SSL, plus tard j'ai configuré le SSL directement dans TOMCAT (afin d'éliminer la possibilité que ce soit le Proxy qui causait le problème) et j'ai toujours le même problème.

Il faut savoir ici que l'application Alfresco tente de se blinder et de faire en sorte que le client enverra toujours et affichera en UTF-8 et enverra ses POST en UTF-8 (en ajoutant l'attribut suivant dans les tag FORM)

<form id="advsearch" name="advsearch" method="post" action="/alfresco/faces/jsp/search/advanced-search.jsp" accept-charset="UTF-8" enctype="application/x-www-form-urlencoded">

—-Notes sur la config TOMCAT dans SERVER.XML—
Configuration SSL utilisé sur le serveur TOMCAT/ALFRESCO
J'ai utilisé la base qui était en commentaire dans le fichier SERVER"XML
 <Connector port="8080" protocol="HTTP/1.1" URIEncoding="UTF-8"
               connectionTimeout="20000"
               redirectPort="8443" />

D'après la doc TOMCAT/APACHE, l'attribut  URIEncoding n'a d'effet que sur les GET. (le nom le dit…)

—- Note sur les informations envoyées dans les headers.
FireFox ajoute, dans son header, avec le POST, un élément
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
(pour voir les Headers, vous pouvez utiliser l'extension FF Ent-têtes http en direct…)
On constate donc que FFox fait un meilleur travail que IE au niveau de l'envoi d'information sur le POST au serveur.
Cependant, ce n'est pas cette directive qui fait que ça fonctionne avec FF car si je l'enlève (toujours avec une extension FF) Ça continue de fonctionner sur FF.

— Note sur un test de base avec un .jsp qui fonctionne AVEC IE ET SSL !!!!.
Voici le code d'un petit formulaire .jsp qui se poste lui même ET QUI UTILISE EXPLICITEMENT request.setCharacterEncoding("UTF8"); pour faire le test, j'ai tout simplement crée directement un fichier ecoding.jsp dans …/tomcat/webapps/alfresco/jsp/content/.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<%@ page
language="java"
contentType="text/html; charset=utf-8"
pageEncoding="utf-8"
import="java.sql.*"
%>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<META name="GENERATOR" content="IBM WebSphere Studio">
<META http-equiv="Content-Style-Type" content="text/css">

<TITLE>Entry_Form.jsp</TITLE>
</HEAD>
<BODY>
<%
try {
request.setCharacterEncoding("UTF8");

out.println("<BR>*** title_text= <BR>" + request.getParameter("title_text") );
out.println("<BR>*** request.getCharacterEncoding()= " + request.getCharacterEncoding() );
out.println("<BR>*** request.getContentType()= " + request.getContentType() );
out.println("<BR>*** request.getLocale()= " + request.getLocale() );
out.flush();

Object key = null;
Object value = null;
int i = 0;
/*java.util.Enumeration enum = request.getAttributeNames();
#while ( enum.hasMoreElements() ) {
#key = enum.nextElement();
#value = request.getAttribute( key.toString() );
#out.println("<BR>– key= " + key + " — " + "value= " + value );
#i++;
#if (i > 200 ) break;
#}*/
} catch ( Exception ex) {
out.println("EXception occured: ");
ex.printStackTrace( new java.io.PrintWriter(out));
out.flush();

ex.printStackTrace();
}
out.flush();

%>



<BR>
<FORM action="testecoding.jsp" enctype="application/x-www-form-urlencoded" name="entryFrm" method="POST">
<TEXTAREA rows="10" cols="40" name="title_text">
          VOS accents ici
</TEXTAREA>
<BR>
<BR>
<INPUT type="submit" name="submitBtn" value="Update">
</FORM>

</BODY>
</HTML>

Voici ce qui est retourné par le form post , on voit qu'École est Ok.
—————————————————
VOS accents ici école
*** request.getCharacterEncoding()= UTF8
*** request.getContentType()= application/x-www-form-urlencoded
*** request.getLocale()= fr_CA
—————————————————
-PISTE DE SOLUTION
La doc tomcat/apache propose d'activer un filter pour activer le décodage systématique des post UTF-8.  http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 j'ai suivi les instruction mais j'ai toujours le même problème.

Merci à ceux qui ont eu le courage de me lire jusqu'au bout ! Toute forme d'aide sera très très appréciée.

Outcomes