First my suggestion, then a bunch of ranting about why- to prove I have similar irks about the suggestion.
Suggestion:
1) do not redirect
2) serve all content (dynamic, static, whatever) which is part of your dynamic application- through the application.
yes, read in the freaking html, spit it out.
Or code it inline with cgi.
Why oh why?
You want to serve dynamic content via dynamic means. And *anything* that is not dynamic, should be served statically!? Right? Makes sense, right? Sounds clean thoughtful.. etc.
Yes.
Fact of the matter is- your application is not a static application. It is a dynamic application. It takes user input.
(i guess if we get more liberal, even serving static pages is a dynamic application at play, user input is a request to apache, and the static content is .. well.. you see my point- but for converstation's sake, normal httpd daemon we refer to as static. Maybe the distinction could be drawn at; if the user client can do something that will change the server data content somehow- like uploading, saving, changing parameters, etc- )
Ok so here's where I'm going with this and it's going to make you cringe. It would to myself as well.
This is *one* possible way to attack the problem. It will feel wrong at first.
Serve static content via dynamic means- as long as the activity is taking part in your dynamic application.
Yes. You heard right.
But why on earth would you! It's just html!!! We don't *need* do this! This is apache! Separation of church and state please!!
Look, there is one very freaking important thing about perl that the high monks keep repeating- Do not optimize off the bat.
Make your application do what it should do. That is #1. Afterwards, optimize...
It should be a lot easier to have a runmode that only serves a "hello" page, a welcome page, that has static content- via your cgiapp- then to serve this as a html page that should only serve if user is logged in- That makes it a runmode.
How many people will use installations of your application? What is your team made up of? How many developers are there?
I suggest keep everything that should be accessible only when you log in via your cgiapp- to be passed via the application.
Yes it's slower.
Yes, apache should do that.
btw, I have a cgi app that is purely about serving static content, html, pdf, whatever. All through a cgiapp, the cgi app is doing the authentication, checking who this is, if they can read this, if they have access and why to this section of things.. it's not a secondary thing to check all that, it's the main thing, content is secondary in that case. For our side at least.
There is also the part where you consider where your time is well spent, and where we may want to let some loose ends be. In favor of more important things.
If later you have a lot of users, many people use installations of the app, this can be revised.
No of course this is not the only option.
This is perl, this is apache, this is likely some kind of unix, so the possibilities are not finite.
By the way, your cgi-bin, although accessible via http, is likely not *in* webshare.. it might be a symlink. There is a difference.
I'm not advocating this is the way to protect content- but.. I just want to throw that out there.
You should have shell access, man symlink.