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

Reply via email to