Am 17.10.2016 um 22:38 schrieb Mark Juszczec:
On Mon, Oct 17, 2016 at 8:20 AM, Rainer Jung <rainer.j...@kippdata.de>
Am 17.10.2016 um 12:35 schrieb Mark Juszczec:
On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas <ma...@apache.org> wrote:
A small hint. I'd expect those to be % encoded.
Thank you very much for your reply.
I've been thinking the problem is lack of % encoding after reading:
*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
<http://en.wikipedia.org/wiki/ASCII>. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded
% escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "
Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?
You can force nod_jk to %-encode the URI before forwarding:
I've tried adding +ForwardURIEscaped in my conf file as follows:
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURIEscaped -ForwardDirectories
I would have expected mod_jk log to show the data % encoded, but it does
text: J O Ë ‹ L
hex: 0x4a 0x4f 0xc3 0x8b 0x4c
I had expected to see something like:
Is that reasonable? Does it make sense?
Could something be turning off the encoding? Do the headers values need to
be set to something specific?
Did you put the directive into the correct VirtualHost?
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org