-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 1/2/2011 7:38 AM, André Warnier wrote: > Well, I would say that by removing the filter nothing changes, then that > proves at least that the filter is useless, doesn't it ? Or that it wasn't actually being used. The filter does have some utility given: 1. Many web browsers submit POST requests without a Content-Type character encoding :( 2. The default request body encoding is ISO-8859-1 per spec If the web app can guarantee that the POST data will be UTF-8 (using UTF-8 encoding in prior-response and in FORM accept-charset), use of the aforementioned filter is recommended technique. > Actually, maybe not. From what I understand of the filter code, it only > sets the request's character encoding if it is not already set. (It does > not do any character translation itself). Yes and no: no actual translation is being done... it's just telling the container how to do the translation. But, the OP has "force" set to true, which means that if the client /does/ send a charset, it will be overridden (which is pretty much a terrible idea). > And, if your form and your browser do their job, the request encoding > should already be set, to "UTF-8". Yes, but many do not do this, even the well-behaved ones like ff and chrome. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0iCVoACgkQ9CaO5/Lv0PDrjACfUAsd3hiGbyO85dpzXDg/NkNK grQAn2A/iiyKMxk4uLgeiAN72cg0yG2z =hYE2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org