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. "
>> from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
>> 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:
> JkOptions +ForwardURIEscaped
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?