https://bz.apache.org/bugzilla/show_bug.cgi?id=57808
--- Comment #8 from Mark Thomas <ma...@apache.org> --- (In reply to Fredrik Jonson from comment #7) > (In reply to Mark Thomas from comment #6) > > > It means you don't have to cache the misses since misses have their own DoS > > potential. > > Is it correct that there are two possible DOS attacks with dynamic charset > loading, i.e with the patch applied: > > 1. force permanent increased memory during runtime with requests that > specify > all avaliable but previously unloaded charsets. > > 2. force expensive charset name/instance lookup misses with requests > that specify non-existent charset names. Just to nit pick, the expensive lookups are (at least were when this code was written) for any Charset (valid or invalid) that are not in the cache. > Any other? > > The consequence of threat 1 is limited. It is self-exhausting as soon as all > available charsets have been loaded once. Agreed. > One mitigation could be to use weak references, if it's worth it? I don't think so. > Threat 2 could be mitigated if charset loading is performed only when the > charset name is valid. Preloading all available charset names on startup > will block threat 2, right? Correct. > Assuming of course that prefetching all charset > names doesn't nullify the memory reduction. I think it does. At keast the way we get the names of the valid charsets currently it does, > BTW, assuming the proposal is accepted, I'd like to see dynamic loading as > the new default, and if necessary an option to make tomcat fall back to the > old pre-loading behaviour. Correct and lean should be the default, not an > option. No objections there. > (N.B I'm not a tomcat committer, just a interested user.) A few good patches can soon change that ;) The discussion in bug 51400 suggests that the performance characteristics we were trying to avoid have changed in Java 7 (i.e. Tomcat 8 onwards). That makes it more important we have some good test results on which to base any decision. -- 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
