tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: <?xml version="1.0" encoding="ISO-8859 in web.xml
Date Wed, 25 Jun 2008 16:55:54 GMT
Hash: SHA1


André Warnier wrote:
| It has been recently shown in a thread in this same forum
| that one does not normally need a filter, and I would submit that using
| a filter as indicated will corrupt data in some instances.

I disagree. The filter is required for clients which silently submit
UTF-8. In that case, the server defaults to ISO-8859-1 and your data is

Your demand that nobody should use GET parameters is unreasonable. Ergo,
the filter is required.

| In the article at
|  >
| there is also a problem in the form shown under the title

Then fix it. You are a member of this community, too, now ;)

| How can I test if my configuration will work correctly?

Create a URL that contains encoded UTF-8 characters that would displayed
differently if interpreted as ISO-8859-1. This is not difficult to do.

For instance,ψ

| As demonstrated by a recent thread here also, the <form> tag as shown,
| is missing a
| enctype="multipart/form-data"
| attribute.

The default form enctype is application/x-www-form-urlencoded, which is
fine when no <input type="file" /> form elements are present (see

| This will cause Tomcat to misinterpret the form data in some cases.
| One could also argue that adding an attribute
| accept-charset="UTF-8"
| would make it even more failsafe.

Fair enough. I'm not sure this affects GET requests generated by forms,
though. Also, not all parameters in GET URLs are from forms: some are
normal links (and are often problematic).

| In addition, the article also repeats a mistake often seen, which is to
| tell people that it's ok to send form data via a GET and use non
| US-ASCII data.  This is a receipe for problems, see the first mentioned
| article at

The only reason it's a recipe for problems is because clients are
inconsistent about their use of character encoding in URLs. Non-ASCII
characters are fine as long as the client and server agree on the
encoding (which is sometimes problematic). Don't confuse the issue of
non-ascii characters in URLs (which is fine) with the inability of
clients and servers to communicate the character encoding properly
(which is not fine).

| Now, I know that these are Wiki articles and can be corrected by anyone,
| but isn't that a problem ? For better or worse, these articles are used
| as reference by Tomcat users.  See your own response above.
| If someone goes ahead and posts incorrect technical stuff there, there
| is a problem, no ?

Yes. If something is wrong, it should be fixed. We might only find out
that it's broken because someone reads it and finds a problem. Given
your passion for the Truth-with-a-capital-T, please correct the article.
Someone in the future may re-correct it if your version of the truth
turns out to be ... lacking.

| I mean that I, as a mere user, don't feel at ease going ahead and
| modifying the Wiki article of someone else unilaterally, nor of posting
| another one saying the previous one is all wrong.  But maybe there
| should be some form of authoritative control of the accuracy of what is
| posted there ?

The Wiki is a wiki so that the documentation can grow organically,
rather than having to wait until some blessed Tomcat developer gets
around to fixing the documentation. The power has been placed into your
hands for a reason. Wikis keep versions, so if you replace everything
with porn, it'll just get reverted and you'll get booted off. Given that
you will likely be making a positive contribution, I'm sure your changes
will stick.

You have to abandon the "us versus them" mentality that you have about
you and the rest of the community. Most of the active users on this list
are not Tomcat developers. There is no "them". There is only "us".

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message