tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Virtual directories, PostResources, and DefaultServlet
Date Tue, 10 Apr 2018 15:38:07 GMT

On 10.04.2018 15:53, Christopher Schultz wrote:
> All,
> I've been asked to take some static files we already have on our
> (reverse-proxied) web servers and require authentication before allowing
> the resources to be fetched by a client.
> One way to do that would be to physically (electronically?) move the
> files from the web servers to the application servers, either as a part
> of the web application itself (tricky due to licensing issues of these
> documents) or as a separate set of files in an arbitrary place on the
> disk e.g. using <PostResources>.
> Before I do that, I was thinking that maybe I could point
> <PostResources> at a (private) URL that points back to the location
> where these files were already available. I was kind of hoping that
> simply doing <PostResources base="http://static/files/here/"
> webAppMount="/static" /> or something like that.
> It looks like the existing WebResourceSet implementations are all
> disk-based resource providers.
> It also seems like writing a simple, read-only, "non-listable"
> implementation of an HTTPResourceSet might work for me.
> So I'm looking for opinions on what I should do, here. I might be able
> to hack-together an HttpResourceSet, but it probably won't benefit from
> e.g. range-requests (the files I am serving are PDFs, which often
> benefit from being able to perform range-requests) and might be fragile.
> I could move the files to the application servers, but then I need to
> make that a part of my app-server build process and I'd like that to
> remain as simple as possible.
> Finally, the files cannot go into revision-control due to licensing
> restrictions, so we basically have to keep them ... "safe" until they
> are deployed.
> Any ideas or suggestions?

I know that when you have a hammer, everything looks like a nail but why not set up a 
separate Apache httpd webserver for these things, and have your reverse-proxies direct the

calls there for them ?
Or, use URLRewriteFilter to redirect these calls to wherever you want.
I'm saying that because it doesn't really sound like you want to mix this up too much with

your Java apps..

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message