-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 1/23/20 5:18 AM, André Warnier (tomcat/perl) wrote: > On 22.01.2020 10:26, Lmhelp1 wrote: >> Hello Chris and all, >> >> Sorry for my late answer. Thank you for the link you suggested me >> to read. Adding the element: >> <request-character-encoding>UTF-8</request-character-encoding> to >> "web.xml" solved my problem. >> > > Glad to hear that. From an absolute point of view, this is of > course again a "patch". But as Chris pointed out before, it is > unfortunately an unavoidable one, due to the fact that the browsers > lamentably fail to always indicate the character set and encoding > that they are using for sending text data to the server. > > [RANT:] (Although they know, and although the specifications > provide them with an easy way to do that. Why that is so is > anyone's guess, but the economic losses due to that over the years > must be staggering). (probably close to the cost of allowing spaces > in directories and files names) +1 It's mind-boggling that browsers do not provide Content-Type with encoding. It is 100% safe to include it, and 100% awful when they do not. The spec says that when the encoding is not included, there is a default. But the browser will change the default and then not communicate it to the server. Breathtakingly stupid. I would also support an HTTP revision that included a Request-Line-Encoding header to tell the server which encoding the client had used to send the request-line, since there is no other way to communicate that. It may require re-interpretation of the request-line, but at least it would be doable at that point. - -chris >> On 17/01/2020 3:17 PM, Christopher Schultz wrote: >>> Your filter changes the encoding of both the request AND the >>> response. It's likely that fixing the request-encoding was >>> necessary, while changing the response-encoding was not. >>> >>> The problem is: >>> >>> 1. The official RFC-defined default character encoding for HTTP >>> is ISO-8859-1. >>> >>> 2. The browser default appears to be unpredictable, but often >>> UTF-8. >>> >>> 3. The browsers have all agreed not to tell the server what >>> characted encoding is actually being used. >>> >>> It's fun. It's a very simply-solved problem: the browser should >>> just advertise the character encoding and everything would be >>> great. Sadly, n o. >>> >>> I would encourage you to read this page in its entirety: >>> https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encodin g >>> >>> >>> - - -chris >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4rAlYACgkQHPApP6U8 pFhfSxAAxzhMaJJynEKKfK8APgx0WOFesiNQH7qoOwzjRw1LA/y3vZMVgoX/K6E/ avj69YD/YQKah/CkhBX/6lOSlGwJRYrpU/dpQOaAjoHJHyeR8ZR3RASmZ5rehsKz Ah1YUysqlsDz7YXtzwKpg1JdW6g+Lkocb0oeniEMVpMFzedtSp5h2/+DbGvIhvzf KDtkiaP+dV2Iap2Upfeg9q5gXina43+CPsscmSXP7CcGZ8XRx2R8B2LzWzcNHA8J k3vC4mTaihD5sLNgFavJ1HT++XM+mwWInzrrWKAToS/LZ++kx+gdXSc3bv8Rgblz 7ByxRDgWZzfrDi+89BOWcrP37A8Ki0Fm5ttUzds+ka/7BE/Q0zu67iXe3beggSBB VucaVT7tFRwFWLXFyUKl42SLADxOTHMI1Sq6ORczYuBV40zFZ84BbSud0O4i84IJ zQHnjadMZXCBK/d9q2W+6gnywljWjconFJmFY1jpbQ7OR32tc9J4s2+ecor6BY4X JLcDzccmPPtT77UBdGQt4g3Y4vcgCGUSJlL6GYqPXCiqp1f6FcrYdbO2kCMpy9BW BHRBgzd43Qo9Y6tKM/BjFcgJJBjVLlQoFYTZw3ggk6GA/UQz2qKEKyg35PuxMSVJ lVM6Mq9lsREar3If3K0g+On3kH9V09VUIr1q4OUpvAJ6BsOoDsA= =7DCg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org