https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #8 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Mark Thomas from comment #6) > 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. What about mutating the "classpath" used by a ClassLoader when it's constructed? That way, we could take the hit of URL -> String -> URL maybe one time for a context. I don't understand the implications of the way the ClassLoader works, so I may be making an insane proposal ;) > 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. If we expect external code to do its own URL-escaping, it doesn't really change the current behavior. I don't think that would be a horrible change, since it would make common cases work (where only Tomcat is involved), and it wouldn't break any of the other cases because they would already be broken (right?). -- 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
