tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Virtual directories, PostResources, and DefaultServlet
Date Tue, 10 Apr 2018 13:53:24 GMT

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?


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

View raw message