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