https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> --- Created attachment 40056 --> https://bz.apache.org/bugzilla/attachment.cgi?id=40056&action=edit Initial implementation as a servlet Filter This is my first effort at a ContentNegotiationFilter which handles the Accept-Language header only. It's not particularly high-performance, but these kinds of things are necessarily slower than the straight-ahead path. I implemented this as a Filter, so it loses several potential benefits of being implemented inside of Tomcat's DefaultServlet: 1. Tomcat's DefaultServlet will know "better" if the file is found or not. This Filter uses ServletContext.getResourcePaths() which may not be the best implementation for discovering if a file exists or not. It also doesn't resolve anything like whether a Servlet should respond, etc. 2. If the file is not found, or if an exist-match is found -- cases where this Filter will take no meaningful action -- the DefaultServlet will have to repeat all of the work to locate the file, etc. If the Filter and the DefaultServlet could work together (because the code is all in the same place), significant performance improvements could be had. 3. Since the DefaultServlet knows how to serve files directly, no request dispatcher.forward() would be necessary if this were implemented in the DefaultServlet. There are probably some security concerns about this naïve implementation, but I wanted to know if I was on the right track for a Filter-based implementation, or if this is something we would want to build directly into the DefaultServlet (maybe only eventually, with a Filter being a stop-gap). -- 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
