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? Thanks, -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
