This is the beginning of another series of comments – there will be at least one more I will post tomorrow, perhaps a third.
If you are reading this posting chances are you are not connected to my Czin web server. As mentioned in the previous post, most of this site now lives being a proxy server located at Pacific University. Yeah, it makes things a little slow since your packets have to traverse the Internet twice – but it continues to run pretty smoothly.
I have begun locking down direct access to Czin – although I deliberately maintained a “back door” via the old URLs of http://unknown8063.homeip.net:88/ and http://bluhelix.homeip.net:88/. These URLs will remain active for at least the rest of the year. The primary reason is that I will have to update RocketLander before I shut down the old URLs.
Migrating my many web sites to the new server topology has been a challenge. The greatest problem to overcome was that several of my server scripts use server variables to detect their location on the server. These techniques were employed to maintain generalization and to enable greater portability. However these techniques backfired when the server was no longer “visible” to the user, but rather to another server. Suddenly these techniques caused the page to “pop out” of the proxy. No good. Luckily I found a clever and almost invisible hack. Since these issues are by definition caused by server-side scripting I merely set a directive to force apache to perpend a small script to the top of all server-scripted pages. This script does an awful and yet brilliant thing. It abuses PHP’s lack of constants by overwriting key server variables with their “expected” values. Even better, the script does this intelligently enough that it leaves pages alone if they are being viewed directly by the user.
Thus, using this technique my server can be accessed both through the proxy and directly even though the URL-space is different.
The techniques described didn’t work on everything, however. My photo gallery proved to be extra special. By modifying the configuration file I was able to resolve most of the problems but certain scripts (like the login/logout functions) refuse to use the correct URL. The gallery’s attempt to be smart is its own downfall. Ultimately I had to add a redirect that catches the photo gallery when it goofs. The result is extra server calls and I hope it’s merely temporary.
For those wondering why I care about being able to access my server directly at all, consider the example of development work. This is a bad example because I do typically use the external URL anyway, but still, I prefer to leave the option open.
Proxy configuration and directory organization
The proxy technique I came up with is actually really simple and intentionally so. My goal was to make the proxy server (hosted at Pacific University) as simple and “dumb” as possible. The only way to commit changes over there is restart the server and unlike mine they actually receive a fair amount of traffic. It is not acceptable for me to be rebooting their Apache service. In other words, I wanted to be able to create an arbitrary amount of subdomains and have the proxy server “just work” for all of them without any additional configuration.
The solution is mod_rewrite. Oh how I used to hate this module and now I am using it like mad, everywhere. With a wild card in the virtual host I setup the server at Pacific to accept all requests from *.bluhelix.com. Then mod_rewrite steps in the capture the subdomain (or the lack of) and choses a URL accordingly. Except for the case of no subdomain, the virtual server proxies to my server at http://czin.bluhelix.com:88/subdomain/. Nothing to it.
So the proxy server doesn’t need any configuration. Period. It doesnt care at all if there is actually something there where it sends it. But my server of course does. But this isn’t bad either. I merely need to (a) create a folder with the exact name of the subdomain, or (b) create rewrite rules of my own to fix the URL to something that exists. An example is when users access the WWW subdomain. There is no folder on my server by that name, mod_rewrite changes it behind the scenes to line up with the folder bhs. In case you’re wondering, the system is generic enough to handle multiple subdomains, however in this case it still maps to only one folder (subdomain1.subdomain2). However I would be free to rewrite this request on my end for maximum flexibility.
To get a feel for what is going on, try accessing http://czin.bluhelix.com:88/gallery/v/Bluhelix/RPG_Point_5/ and note what happens to the URL.
A couple notes about server-relative URLs:
While I have not tested these fully, you may encounter unexpected results stemming from the fact that the server-side scripts are going to see a different server root than the client. I suggest sticking with document-relative URLs for ALL purposes on my server because they are simply going to produce more success. If you must, realize that server-side scripts see the “real” server root, which is typically one folder down from where the client “thinks” it is. Hyperlinks and client scripts will tend to go with what you see – which makes sense since they are executing from your viewpoint, not the server’s. So if your site is located at mysite.bluhelix.com, you server scripts will see the index.php page at /mysite/index.php while a hyperlink will find it at /index.php. A significant disadvantage to using server-relative URLs is that you will effectively break your site when viewed outside the proxy.
Unknown8063 Inside BluHelix