As Tony and I were discussing, perhaps we should not make the unescaped
query string available as an env. variable at all but simply put it on the
command line.
* Otherwise agreed, but I'd still wish you'd consider doing it like
* I did, which would cause command line:
*
* script /extra/path 'foo=' 'bar' 'bar=' 'foo'
*
* In this case equal signs in values (or even names) wouldn't cause
* any confusion, and spaces in values aren't a problem, either.
But the equal signs are frivolous, and the script just has to parse them out
anyway. So why put them in there?
* At least for CERN server it *must* be a virtual path, because the
* rule file starts protecting already before the filesystem path is
* found out. Otherwise I'd have to be able to translate filesystem
* path back to virtual path which is indeterministic.
*/
Hmmmm. Here's the two choices as I see them.
1. A full real pathname
Pluses: Flexibility. Any file can be returned.
Minuses: Security. These files don't necessarily have to be subject to
access control.
2. A virtual pathname
Pluses: Security. Only normally servable documents are allowed.
Minuses: Must return documents that are normally available to the client.
As far as implementation, I can easily do either. The question is, then,
what will the scripts want? Would it be difficult with the CERN server to
enter the document mapping process with an already translated pathname? If
it's overly difficult, and scripts do not necessarily want to return outside
documents, we should pick the virtual path. Tony, which method would be
easier for Plexus?
--Rob