https://bz.apache.org/bugzilla/show_bug.cgi?id=59001

--- Comment #6 from Mark Thomas <ma...@apache.org> ---
I really wanted to fix this but I'm not sure that supporting this use case is
worth the cost.

There are two places I have found (so far) where changes would be required. The
first is during start-up to ensure that the paths used to construct the URLs
for the class loaders escape "!/" to "%21/".

The second is in the web resources implementation where FileResource.getURL()
needs to escape "!/" to "%21/".

The problem stems from the fact that the only way to do this escaping (that I
have been able to find) is URL -> toString() -> replaceAll() -> new URL(). And
that is relatively expensive.

I'm not concerned about startup. That is a one-off cost. What concerns me is
the performance impact of adding this to FileResource.getURL(). That gets
called a lot. I'm concerned that the impact of adding this escaping is going to
be measurable for end users.

The other option is to take the position that anytime code constructs a jar
URL, that code is responsible for ensuring that any !/ sequences in the path it
uses to construct that URL are escaped. While we could do this in Tomcat (there
are ~20 places we'd need to fix this), I suspect a whole bunch of third-party
code won't handle this correctly. And this is before we get into the mess that
is JARs in WARs.

Given that most users don't need this (I don't recall seeing this issue
reported previously and that's going back to Tomcat 4.1.x) I'm leaning heavily
towards WONTFIX. There is going to need to be a really good reason to fix this
to change my mind.

-- 
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

Reply via email to