Am 03.02.2019 um 22:20 schrieb Garret Wilson:
Hi, all. I've stumbled on a situation I need some clarity on. As is
typical, there's all sorts of information floating around, most of it
more than a decade old, with no indication of what the current status is.
Our team is creating a RESTful API (using JAX-RS implemented by
RESTEasy) to a general semantic framework in which each "thing" is
identified by a URI. (The framework is URF <https://urf.io/>, but that's
a story for another day. It's analogous to RDF.) Basically we want to
issue a GET to https://example.com/{thingURI}/description to get back
info about the "thing".
If we want to look up the thing identified by
https://example.info/foobar, we would need to issue a request to
https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description .
That should be completely legal and spec-compliant, and has been since
web time began.
You no doubt already know the problem: Tomcat won't allow encoded
slashes unless one sets system property
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
Apparently this there was a bug somewhere in Tomcat 6
<https://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities>
(back in 2007!) when used behind a proxy, as Mark explained on Stack
Overflow <https://stackoverflow.com/a/19584499/421049>. Tomcat 6 is
really old, and Mark's Stack Overflow message seems to hint that it's
not an issue anymore.
I'm not one to blindly change a setting unless I know what it's doing,
and complain/advocate for change if it's no longer relevant. So I'm full
of questions:
* Is this even an issue anymore? Of not, is there a reason not to make
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH default to
true?
* If this setting is still needed in some cases, is there any way to
control it without resorting to a system property? (System
properties are not very flexible, and Tomcat has many layers of more
manipulable settings, as you all would know better than me.)
* If we enable encoded slashes in Tomcat, do we need to do anything in
Apache to get this to work if we put it in front of Tomcat? One
really old Stack Overflow post
<https://stackoverflow.com/a/4443129/421049> indicated that there
used to be a bug with AllowEncodedSlashes not being inherited by
Apache virtual hosts. See also
https://issues.sonatype.org/browse/NEXUS-10570 .
Looking at the code in server/core.c in the current 2.4.x, merging
config is implemented in merge_core_dir_configs() and indeed the
sessiongs for AllowEncodedSlashes are not inherited from the global
server into virtual hosts but instead overwritten by what is set in the
virtual host inluding its default values. So yes, you need to explicitly
set it in virtual hosts. This has been fixed in trunk in 2013
(r1496339), but was not ported back to 2.4 probably due to compatibility
reasons.
* Do we need special configuration of mod_kj? (I haven't connected
Apache to Tomcat in a while; I'm not sure the current best
practices. I'll have to read up on that.) The connectors
documentation
<https://tomcat.apache.org/connectors-doc/reference/apache.html> is
mentioning things like ForwardURIEscaped, which looks like it may be
related.
In addition to Mark's response: once your web server config needs to
change the original URL, e.g. by mod_rewrite, it will likely decode at
least parts of the URL to operate on a normalized URL. Once that
happens, there's no obvious way back to an encoded URL that is
consistent with the original one. Encoding is not really the reverse of
decoding, eg. when a character does not have to be encoded, but was
encoded in the original URL, the sequence decode then encode will not
encode it back.
You might want to set AllowEncodedSlashes NoDecode and test it.
See http://tomcat.apache.org/connectors-doc/common_howto/proxy.html,
especially "URL Encoding" and for details of some of the
non-recommeneded options
http://tomcat.apache.org/connectors-doc/reference/apache.html especially
"Forwarding".
I'm not even sure I asked all the right questions, but basically: I want
to uses encoded slashes in my request URIs. What's the latest situation
on that?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
