Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
All- i know this is slightly offtopic, but I am at the end of my rope here: I have an extremely esoteric Apache issue, and I was hoping to track down a possible solution. If I could enlist your help, i would appreciate it. The problem is below: I have a module that supports file type .xxx This module has the ability to hand the translation of type .xxx to a remote server (allowing me to place the file type translator on a separate server for security/performance reasons). Now, the problem is, is that Apache, before it will pass the request to the handler/translator, it first checks to see if the file exists on the local disk. This is a problem, because it forces me to populate the files (say, foo.xxx) across both the main webserver and the server that handles translation for example: user A request file http://www.boo.com/foo.xxx Now, apache accepts the request, and searches the local disk for foo.xxx, when it finds foo.xxx, it passes the translation onto mod_xxxtranslator.so which in turn opens a connection to port 9999 on server B and has the file foo.xxx (which exists on server B physically) translated, and passed back to the first server, apache then gives user A the requested, translated file. What I need to cut out, is the first Apache server's actual file system check, in other words, it does not search the local disk for file type .XXX, instead, it immediately throw the request directly to the module, which parses the second server. now, i do not know of this is an Apache directive, or a module compilation option, but any help or pointers would be greatly appreciated. Jesse Noller Email: jnoller at allaire.com Phone: (617) 252-5847 - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |