https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #9 from Mark Thomas <ma...@apache.org> --- (In reply to Christopher Schultz from comment #8) > (In reply to Mark Thomas from comment #6) > > 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 ;) That is exactly what I am proposing for start-up. It is a one-off cost so no big deal. > > 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?). I'm still on the fence about this (and that is without looking at the JAR in WAR issue). I've thought of a few ways we could make FileResource.getURL() handle this without being horribly slow unless you have a path that includes a !/ sequence (in which case being slow is the price you pay for it working) but I'm becoming less convinced that this is the way to go. The more I think about it, the more I am leaning towards the view that if you take a string and use it to construct a JAR URL then you are responsible for making sure any "!/" sequences are escaped. Before heading down that route I'd want to check how often the ~20 places we'd need to do this are called. -- 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
