Chris,
Christopher Schultz wrote:
[...]
there's a somewhat obvious way to encode your
headers (including Japanese or other non-ASCII characters) so they will
work:
java.net.URLEncoder.encode(text, "ASCII")
You'll get a string like "foobar%45%67%65%43%45%45%78%69...". You just
have to remember to decode the string on the other end in a similar way
(java.net.URLDecoder).
Yes, but in my humble opinion you would be, as they say, "cruising for a
bruise". Your very example above demonstrates the bruise potential.
If the string contained any Japanese characters, what would happen is :
- the string would first be converted to ASCII. Since ASCII does not
support Japanese characters, you would get a string with plenty of "???"
characters (unless java.net.URLEncoder triggers an exception for that).
- then this string would be URL-encoded, converting the embedded "???"
into their percent-encoded representation.
...and there is thus no chance at all that the server would ever be able
to retrieve the original Japanese characters.
So let's say that we rectify your undoubtedly slip of the keyboard
mistake above, and replace this by :
java.net.URLEncoder.encode(text, "UTF-8")
And let's say that the client and server have somehow (?) agreed on this
in advance, and also agreed that they will do this only in headers
clearly marked as non-standard (á la X-header-name:), and agreed in
advance in which headers, and agreed in advance that they will both use
the same encoding.
Then, the server application would presumably obtain the content of this
header via a request.getHeader("X-header-name"), and receive a Unicode
string containing "foobar%45%67%65%43%45%45%78%69...".
It would then decode it using java.net.URLEncoder.decode(text, "UTF-8"),
in order to obtain back the original string.
And it would work fine.
But in a totally non-portable way (meaning just between that client and
that application), and with just too many conditional tenses to make
this comfortable.
Once again, I think what we are bumping against is a shortcoming of the
HTTP protocol, but until such a time as the powers-that-be at that level
decide to publish another revision, I think it is safer to stick to the
one we've got.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
