https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Bug ID: 62459
Summary: mod_jk: Forwarding URLs containing escaped slashes
(e.g. for REST services) fail with syntactical-wrong
double-escaping
Product: Tomcat Connectors
Version: 1.2.42
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_jk
Assignee: dev@tomcat.apache.org
Reporter: g.jae...@dnb.de
Target Milestone: ---
The RFC defines that it's not forbidden to use a slash ('/') itself within the
entity payload of a path element of an URL, but this have to be encoded in the
well known manner ("%2F").
One (like us) will need the feature for an implementation of REST-Service.
For reasons of security, one have to enable the processing of slash as a
allowed character of the URL, one have explicit to enable this inside a VHost
of the Apache httpd, first. This option is named 'AllowEncodedSlashes'. With
the default ('Off'), an URL containing an encoded slash will be rejected (with
an RC 404). A value of "On" will allow the processing, but the incoming '%2F'
will be unescaped with no care of the semantic, which is pointless if it's
inside a path element. The value "NoDecode" will allow "%2F" an keep it
encoded.
Now, it's up to mod_jk to forwarded this URL to the application server. There
are four implemented methods, choosen by '+ForwardURIxxx'. The current default
(since 1.2.24) is called "+ForwardURIProxy" which may be treated as an
successor of the former "ForwardURICompatUnparsed" (1.2.23) and
"ForwardURICompat" (1.2.22)
I think the current "+ForwardURIProxy" is meant to address and solve such
problems. But it don't catch this here. It's said that ["the forwarded URI will
be partially reencoded after processing inside Apache and before forwarding"].
And this will be done without care about the semantic part of the URL. Here,
the precent character of the "saved" representation of the slash (as '%2F')
will be re-encoded as '%25'. This result into forwarding an syntactical wrong
URL containing the string '%252F' to the application server.
As a "unacceptable" workaround, one may use the mode
"+ForwardURICompatUnparsed" for mod_jk. This will advise mod_jk to forward the
original unprocessed copy of the incoming URL instead of the httpd enginge
current representation. This override all other URL processing done so far by
other modules; with other words you can't use any other tooling like
mod_rewrite in this case.
It may be difficult to detect at the code path of mod_jk that some levels
before some code within the httpd have "saved" the escaped slash. But I think
it should be correct by heuristic to *not* encode a percent ('%') if (and only
if) it's followed by the hexdigits '2F' at this place, because there should be
no other source for this as from the httpd option "AllowEncodedSlashes
NoDecode". A correct implementation will take account of the semantic parts of
the URL, the value of this option and will avoid the wrong double-escaping
('%252F') just in the right case.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
