The `Other Variable` In The Conditions

[loloyd]

I was trying to add a condition wherein the requested path is not an Abyss alias but I couldn't find any Variable that would serve my purpose - certainly not REQUEST_URI, REQUEST_URL, nor REQUEST_FILENAME. So I got intrigued with the "Other" Variable. Does this "Other" Variable only refer to variables obtainable from phpinfo()? There is not much information on the contextual help pages on this topic. Maybe somebody can shed some insightful light on this.

Maybe I should post this as a feature suggestion? I mean - to add a variable named as "Web Server Alias" and the usual bunch of Operators can apply here (Matches with, Does not match with, =, <>, etc.). This would help in the ease of maintaining our URL rewriting rules.
_________________

http://home.loloyd.com/ is online if the logo graphic at left is showing.

[aprelium-beta]

loloyd,

"Other variable" means any CGI variable that the server may export about a request. They are listed in the documentation in the CGI variables section. You could also dump them using a simple SSI page:

[loloyd]

(Post have been removed for putting foot in mouth - I apologize).
_________________

http://home.loloyd.com/ is online if the logo graphic at left is showing.

[loloyd]

I may have erred in my previous illustration of the scenario - sorry about that.

In this example, imagine the many aliases I have to contend with, instead of simply having an equivalent condition like:
REQUEST_URI Doesn't match an alias

Simply specifying the following conditions does not work as it presumably should:

Variable|Operator|(value)
REQUEST_URI Is not a directory
REQUEST_URI Is not a file

The following condition basically represent my aliases table - so there is a redundancy of effort, specifying the names of virtual directories in my alias table and then specifying those aliases here:


_________________

http://home.loloyd.com/ is online if the logo graphic at left is showing.

[loloyd]

Hmm... I think I solved my own [strikethrough]problem[/strikethrough] stupidity.

I tried the obscure REQUEST_URL variable and it appears to work. I don't think this variable is listed in any CGI specification.

---
Edit: OK, it's official. I've gotten crazy.

I was amazed at how REQUEST_URL was working so well - and so I removed my aliases in my conditions list. To my chagrin, however, my Drupal site then failed to work properly anymore.

I conclude that Drupal's way of supporting URL-Rewrites may not be "smoothly" compatible with Abyss's way. *Sigh*. Back to the old ways/drawing board for me.
_________________

http://home.loloyd.com/ is online if the logo graphic at left is showing.

[pkSML]

Sounds like your whole site is based on aliases!
As a rule, I try not to use them. Many fewer headaches - especially when scripting (file paths vs. URL paths).

If you can, get rid of the aliases.
_________________
Stephen
Need a LitlURL?

http://CodeBin.yi.org

[loloyd]

I have to (rely on aliases), especially on intranet sites. Some of my intranet sites rely on voluminous shareable data spread on various hard drives - highlighting the need for aliases. Hey, I can't put them all in just one basket of a 160 GB right? :P
_________________

http://home.loloyd.com/ is online if the logo graphic at left is showing.

[aprelium]

loloyd,

We get the idea. What you're asking for could be solved by having the option to check a URL rewriting rule after resolving the aliases and mapping paths (the checks . That would be a nice addition to the URL rewriting system.
_________________
Support Team
Aprelium - http://www.aprelium.com