Am 12.10.19 um 17:13 schrieb Garret Wilson: > Could somebody at least point me to the best place to wire in > site-level per-resource redirects in embedded Tomcat? I can create a > solution, I just need to know where it is best to start.
Did you look at https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html Felix > > Thanks, > > Garret > > On 10/11/2019 11:06 AM, Garret Wilson wrote: >> This is a question for Tomcat experts before I get started >> implementing a new feature. >> >> Let's say I'm embedding Tomcat to serve static files. At the time of >> creation I know that certain paths, such as `foo/bar.txt`, should >> redirect to other paths, such as `some/other.txt`. What's the best >> way to configure Tomcat to do those redirects? I'm comfortable with >> extending the source code. >> >> Here are a couple of ideas that come to mind: >> >> * I could create a redirect servlet and map different instances of it >> to different targets in the context when I configure everything. But >> in Tomcat's routing engine, is the most efficient way to do things? >> (I assume that the servlet mappings can be placed "over" the default >> servlet's path space, that is, cherry-pick paths for redirection, >> falling back to the default file-serving servlet for non-redirect >> paths.) >> * I thought of patching into the default file servlet, overriding >> `org.apache.catalina.WebResource`, and creating virtual >> `RedirectResource` resources that don't correspond to any physical >> file. However it's not obvious to me where I would create a >> redirect. Maybe throw some redirect exception inside >> `WebResource.getInputStream()`? (This is probably not correct. I'm >> just brainstorming. The idea is sound if I knew where to put it.) >> * Should I install a configured rewrite valve when I'm setting up >> embedded Tomcat? >> * Is there some other routing logic in Tomcat I could tap into most >> efficiently, providing a known set of redirects? >> >> Thanks for any guidance. I'm want to figure out the best way to >> attack this before getting very deep in an implementation. >> >> Garret >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org