Once a link identifier ($link) to a database is opened, PHP strings can be cleaned up using $safe_string = mysql_real_escape_string($unsafe_string, $link);

This is simple and convenient. Below is a similar function to get a feel for what mysql_real_escape_string() is doing. function escape($str) { $search=array("\\","\0","\n","\r","\x1a","'",'"'); $replace=array("\\\\","\\0","\\n","\\r","\Z","\'",'\"'); return str_replace($search,$replace,$str); }
source: http://php.net/manual/en/function.mysql-escape-string.php

I have written a wrapper class for PHP’s mysql functions that can help with escaping data using mysql_real_escape_string() for safe database insertions. Additionally, it generally reduces the clutter that PHP’s built in query functions can cause.

The basic idea is that the class can be instantiated with $query = new MySqlDB($hostname, $database, $username, $password);

And then queries can be executed and an array containing the results can be easily captured like so $query->executeQuery('SELECT * FROM `Table` WHERE `Field1` = %s AND `Field2` = %d', 'string', 12); while ($row = $query->fetchArray()) { $field3 = $row['Field3']; // do something amazing }

The query parameter is treated as a format string of sorts where %s is cast as a string and %d is cast as an integer from the provided list of arguments. A query string and arguments can also be provided directly into the fetchArray() call for a single line return of the first row. There are also methods to return a single value returned by the query and one to return all rows in a single array.

Some other cool things you can do // Inserts a row into 'Table' where Field1 = 'string' and Field2 = 12 $insert = array('Field1' => 'string', 'Field2' => 12); $query->insertAssoc('Table', $insert); // Updates row where Field3 = 10 $update = array('Field1 => 'string', 'Field2' => 12); $query->updateAssoc('Table', $update, 'Field3 = %d', 10);

You can download MySqlDB on my in my snippets page or here.

Overview

The primary weakness of the rSync bash script covered in part 1 when backing up a Windows computer is that it is unable to transfer any file that might be open by the user or operating system. Microsoft includes a backup application (NTBackup) beginning in Windows XP Service Pack 1 and Windows 2003 that gets around this problem by creating its backup from a volume shadow copy. The Volume Shadow Copy creates a snapshot of a specific volume at a specific point in time. This allows one to backup every file in a volume without the possibility of any being open or partially written to by an application.

Using the volume shadow copy requires a bit of black magic. We’ll need to obtain vshadow.exe from one of Microsoft’s freely available SDK’s. Very few programs understand the URI for a volume shadow copy, including rSync, so we’ll also need an application capable of mapping a volume shadow copy to a standard Windows drive letter. The solution is an small program called dosdev.exe, which is a wrapper around DefineDosDevice( ) Win32 API.

Setup

For our setup we will have two machines. The Mirror (192.168.1.2) will be the rSync backup server running a *nix operating system. The Mirror will create snapshots of the Target (192.168.1.3) which is running either Windows XP or Windows Vista. I will be sure to note when the two Windows operating systems differ in our setup.

Required software for the Mirror

• OpenSSH
• rSync
• Expect

Required software for the Target

• cwRsync
• CopSSH
• vshadow.exe
• dosdev.exe

The software needed on the Mirror is pretty minimal, assuming you already setup the snapshot-based backup covered in part 1. The one new thing we’ll need is Expect so we can write a short Expect Script.

For Windows, we’ll need a Windows based rSync. I picked cwRsync because it is easy to install and runs from Cygwin, which we’ll need. There is no need to install Cygwin, however, as cwRsync comes with all the required Cygwin binaries in the installer. You can find cwRsync at their site: http://www.itefix.no/i2/node/10650

Install cwRsync to the folder of your choice. Next, download CopSSH. CopSSH is also a straight forward to install and setup SSH server for Windows. The program is Cygwin based, and again, includes all the Cygwin binaries needed to do its job. The trick here is, we want to install CopSSH to the same location as cwRsync so we avoid having two instances of Cygwin running simultaneously.

Next, we’ll need vshadow.exe. For Windows XP and 2003 users, you can download Microsoft’s Volume Shadow Copy Service SDK. Vista user’s need to download the Windows Vista SDK Update. It is very important you obtain the correct version of vshadow.exe. For instance, the Windows XP and 2003 versions are different and will be found in different directories after the SDK is installed. If you encounter errors when running vshadow.exe, then do verify you grabbed the correct file. I suggest copying vshadow.exe and placing it in either the Cygwin bin folder or your System32 folder in Windows. You may uninstall the SDK if you prefer – we only need vshadow.exe.

Finally, we need dosdev.exe. This program is very obscure. To get the exe from Microsoft, download MPSRPT_CLUSTER.EXE. If you have a program like 7zip you can extract dosdev.exe directly from the installer. Otherwise you will need to install the report application and copy dosdev.exe from it. Again, I suggest copying dosdev.exe and placing it in either the Cygwin bin folder or your System32 folder in Windows. DO NOT EXECUTE the report…

Once everything is installed, activate a CopSSH user. This can be done easily by launching the activate user wizard from the CopSSH start menu entry. In order to execute vshadow.exe you need to activate a user with Administrator privledges. In Vista, this probably means the hidden Administrator account. Vista users, please follow this How to guide to enable the hidden Administrator account and assign it a password. If you prefer, you may then hide the account from the login screen.

Scripts

For this setup we’ll need (sadly) eight files: four on the Mirror and four more on the Target machine. Place all the Mirror files in the same directory and I have them creating the snapshot in /snapshot. For the Target, I left all four files in the Administrator’s home dir at C:\Program Files\cwRsync\home\Administrator. I plopped a copy of vshadow.exe and dosdev.exe in C:\Program Files\cwRsync\bin so that I could execute them like the Cygwin command line programs. Again, C:\Windows\System32 would also work. Replace all instances of “password123″ with your Administrator’s password. However, the rSync daemon password need not be the same as your Windows authentication password.

General idea

1. backup.sh is initiated manually or from a scheduled cron entry
2. backup.sh cleans up extra files in case the previous execution failed to complete
3. backup.sh uses an expect script to log into Target via a password authenticated SSH session and begins vshadow.exe as a background process.
4. backup.sh waits on a VB script that is started remotely to sleep until the rSyncd pid file is detected
5. vshadow.exe executes a CMD script that maps a volume shadow copy with dosdev.exe and then begins a rSync daemon
6. rSync daemon creates a pid file and listens for a connection
7. Remote VB script detects the rSyncd pid file and terminates, allowing the bash script to continue
8. backup.sh begins the rSync transfer process, which connects to the daemon running on the remote machine
9. After the transfer is complete, backup.sh kills the daemon process on the remote machine
10. With the rSync daemon terminated, the CMD script continues and unmaps the drive letter used for the volume shadow copy.
11. vshadow.exe completes and destroys the volume shadow copy.
12. backup.sh cleans up extra files and terminates.

Mirror

• backup.sh
• exclude_users
• rsync.secret
• sshlogin.exp

Target

• rsyncd.secrets
• sleep-rsyncd.vbs
• vsrsync.cmd
• rsyncd.conf

• The files backup.sh and exclude_users are recognizably close to what we used in part 1. If you are a Vista user do note that you will need to exclude certain junctions and soft links that Microsoft included to maintain XP-like paths or rSync will error and/or backup the same files more than once. The junctions might be surprising to some Windows users since Vista OS keeps them hidden from the user during normal use.
• There are some differences between my backup.sh on XP and Vista; however, it turns out the Vista version will run on XP so I will only provide my Vista script in this guide to keep things simpler.
• Notice that we call vshadow.exe and taskkill using an expect script rather than the usual public key authentication. Public key authentication in Cygwin/SSH bypasses Windows authentication (because no Windows password was provided to authenticate) and in Cygwin 1.5.x, the version I used in my setup, the context switch used to support public key authentication causes a slight difference in the environment that prevents vshadow.exe from running successfully. The win32 app taskkill also fails on Vista when used with public key authentication (it completed successfully on XP, however).
• For some reason the PID printed to the rsyncd pid file in Vista was inaccurate. In XP it was correct and I used the contents of the pid file to kill the process.
• Also take note that we’re using a rSync clinet/daemon model instead of tunneling rSync over SSH. This means we’ll need a password file to avoid an interactive password prompt and our transfer is sent over the clear instead of being encrypted. Advanced users may consider tunneling rSync over STunnel to achieve encryption.
• We set the modify window parameter to 2 seconds to the 2 second timestamp resolution of FAT32 file systems.
• Finally, while Windows paths are not case sensitive, *nix and by extension, Cygwin, paths are. On my XP machine the Windows directory is all capitals, so be sure to verify the casing in the paths I entered below match your system.

backup.sh #!/bin/bash unset PATH # USER VARIABLES BACKUPDIR=/snapshots # Folder on the backup server where the backups shall be located KEY=/root/rsync/rsync-key # SSH key TARGET_HOST=192.168.1.3 # The address of the production server TARGET_USER=Administrator # The user of the production server EXCLUDES_USERS=/root/backup/exclude_users # File containing the excluded directories DAYS=30 # The number of days after which old backups will be deleted # PATH VARIABLES CSCRIPT=/cygdrive/c/Windows/System32/cscript.exe # Remote location of cscript exe TASKKILL=/cygdrive/c/Windows/System32/taskkill.exe # Remote location of taskkill.exe CAT=/bin/cat # Remote location of cat bin SED=/bin/sed # Remote location of sed bin CP=/bin/cp; # Location of the cp bin FIND=/usr/bin/find; # Location of the find bin ECHO=/bin/echo; # Location of the echo bin MK=/bin/mkdir; # Location of the mk bin SSH=/usr/bin/ssh; # Location of the ssh bin DATE=/bin/date; # Location of the date bin RM=/bin/rm; # Location of the rm bin GREP=/bin/grep; # Location of the grep bin RSYNC=/usr/bin/rsync; # Location of the rsync bin TOUCH=/bin/touch; # Location of the touch bin ## ## ## -- DO NOT EDIT BELOW THIS HERE -- ## ## ## # CREATING NECESSARY FOLDERS $MK $BACKUPDIR CURRENT=$BACKUPDIR/current OLD=$BACKUPDIR/old $MK $CURRENT $MK $OLD # CREATING CURRENT DATE / TIME NOW=`$DATE '+%Y-%m'-%d_%H:%M` NOW=$OLD/$NOW $MK $NOW # INITIALIZE VOLUME SHADOW COPY AND RSYNC DAEMON $SSH -i $KEY $TARGET_USER@$TARGET_HOST "rm rsyncd.pid" ./sshlogin.exp $TARGET_USER@$TARGET_HOST \ "vshadow.exe -script=vss-setvar.cmd -exec=vsrsync.cmd C\:" & # SLEEP UNTIL RSYNCD PID FILE IS FOUND $SSH -i $KEY $TARGET_USER@$TARGET_HOST "$CSCRIPT sleep-rsyncd.vbs" # RUN RSYNC INTO CURRENT $RSYNC \ -apvz --delete --delete-excluded \ --exclude-from="$EXCLUDES_USERS" \ --password-file=rsync.secret \ --modify-window=2 \ $TARGET_USER@$TARGET_HOST::C/Users/ \ $CURRENT ; # TERMINATE RSYNC DAEMON AND VOLUME SHADOW COPY ./sshlogin.exp $TARGET_USER@$TARGET_HOST "$TASKKILL -f -im rsync.exe" $SSH -i $KEY $TARGET_USER@$TARGET_HOST "rm rsyncd.pid vss-setvar.cmd" # UPDATE THE MTIME TO REFELCT THE SNAPSHOT TIME $TOUCH $BACKUPDIR/current # MAKE HARDLINK COPY $CP -al $CURRENT/* $NOW # REMOVE OLD BACKUPS for FILE in "$( $FIND $OLD -maxdepth 1 -type d -mtime +$DAYS )" do $RM -Rf $FILE # $ECHO $FILE done exit 0

sshlogin #!/usr/bin/expect -f # set Variables # set password [lindex $argv 0] set host [lindex $argv 0] set scriptname [lindex $argv 1] set timeout -1 # now connect to remote UNIX box (ipaddr) with given script to execute spawn ssh -p 22 $host $scriptname match_max 100000 expect { -re ".*Are.*.*yes.*no.*" { send "yes\n" expect { ">" { } "$" { } } exp_continue #look for the password prompt } "assword:" { send -- "password123\n" expect { ">" { } "$" { } } #the expect command will now return } default { send_user "Login failed\n" exit } } sleep 2 send_user "Finished\n" exit

rsync.secret password123

• For the Target machine we’ll need a CMD and VB Script, as well as a configuration file for the rSync daemon.
• Volume shadow copies in XP and Vista are temporary and only exist as long as the process that created it exists. In our case the process that creates the volume shadow copy is vshadow.exe (Windows 2003 users can create a persistent volume shadow copy). Fortunately, vshadow.exe allows us to send it a CMD script to execute – hence the purpose of vsrsync.cmd below. vsrsync.cmd executes after the volume shadow copy is created but before it is destroyed. During this time we need to use dosdev to map the volume shadow copy to a standard Windows drive letter that rSync can read from. Next, it will create the rSync daemon using a configuration file and secrets file. And finally, after the remote script kills the rSync daemon process, the CMD script will unmap the volume shadow copy drive letter.
• Because we need to initiate the rSync transfer after the volume shadow copy is created but before it is destroyed, we need a small VB Script that halts the remote script from executing until it detects the daemon is ready to begin the transfer. It performs this check by watching for the rSyncd pid file.

rsyncd.secrets Administrator:password123

sleep-rsyncd.vbs Const Flag = "C:\Program Files\cwRsync\home\Administrator\rsyncd.pid" While DoesFileExist(Flag)=0 wscript.sleep 10000 Wend function DoesFileExist(FilePath) Dim fso Set fso = CreateObject("Scripting.FileSystemObject") if not fso.FileExists(FilePath) then DoesFileExist = 0 else DoesFileExist = 1 end if Set fso = Nothing end function

vsrsync.cmd @ECHO OFF call vss-setvar.cmd SET PATH=%PATH%;"C:\Program Files\cwRsync\bin" dosdev X: %SHADOW_DEVICE_1% rsync --daemon --config=rsyncd.conf --no-detach dosdev -r -d X:

rsyncd.conf use chroot = false strict modes = false pid file = rsyncd.pid [C] path = /cygdrive/X/ read only = yes ignore nonreadable = yes hosts allow = 192.168.1.2 auth users = Administrator secrets file = rsyncd.secrets

I hope this guide provided some help to anyone wanting to setup something similar. My setup is largely based on the one covered at http://www.goodjobsucking.com/?p=62

Additional notes

• If you have files with special characters in the file name, you may need to upgrade your Cygwin DLL to the Unicode aware version.
  • http://phaq.phunsites.net/2006/10/28/interoperability-problems-samba-windows-rsync-and-unicode/
  • http://www.okisoft.co.jp/esc/utf8-cygwin/
• There are a lot of moving parts in the above script. If something hangs or you just need to abort and try again you may need to reboot the Windows machine to ensure all the pieces are ready for another trial. In my experience, however, killing the rSync process from Task Manager was frequently enough to bring the entire script back to a state where I could try another test run.
• cwRsync will simply abort execution if the pid file already exists. My script has an extra delete before vshadow.exe is called to try and avoid this problem.
• vshadow.exe will fail on XP and Vista if another instance of it is already running on the same volume.

For my personal computer, I have used file sync tools like SyncBack to maintain a mirror of my documents on an external hard drive. However, with a web server and other computers in my network a more centralized approach became very appealing.

Having a spare computer lying around and enough money to invest in a pair of hard drives I set out to give an old PC a new purpose in life – to become my network’s dedicated backup server. I didn’t want to have to maintain scheduling policies on each machine (what a pain) so I also wanted my server to be able to pull backups directly from each computer in my network. Additionally, I wanted to keep the option of setting up the backup server in a remote location to further protect my data – so Samba was something I wanted to avoid, if possible.

At first I was drawn to a project called RESTORE which is an easy to get rolling multiplatform backup system built on Xubuntu. I had difficulty getting it to backup a Windows system, however. SFTP to a Windows machine seemed to be broken and Windows share connections was not reliable. And again, I preferred to stay away from Windows shares anyhow.

So I turned my attention to an old tool in the *nix world known as rSync. My friend at Benford Does Stuff pointed me to the tool. He setup a backup server that used rSync to mirror a web server we used to maintain at our University. After sending me to a pair of HowTo guides I was well on my way to scripting my own incremental snapshot backup of my web server.

You may find the guides below

• Mirror Your Web Site With rsync
• Create Incremental Snapshot-style Backups With rSync And SSH

The above solution works great and I am using exactly that to snapshot my web server running Ubuntu Server 8.04.

With some minor tweaking the above script will snapshot a Windows-based computer decently. In particular, however, the script falls short when attempting to backup files that are currently open by the user or operating system. Open files on a Windows system are locked and cannot be read by other applications. There is a resolution but instructions and examples are rare, and I spent a considerable amount of time getting it working right in my setup. In my next article I will detail the modifications I made to Stephan Jau’s incremental snapshot script to mirror my windows systems.

Quite a change from 3 years ago when we ran the server on a windows machine with 92 MB of RAM

However, the server upgrade is nice. It now runs on a hyper threaded P4 clocking at 2.8 GHz. That’s twice as fast as the previous CPU in clock speed alone. I also threw in two extra sticks of RAM since the new motherboard has two slots more than the previous system. We’re only at 1.5 GB RAM at this point but I’m looking into upgrades. Incidentally, the new motherboard only has SATA connectors so I had to toss out the old hard drives and add a single large-ish one. So the server got a bit of unplanned capacity in the upgrade as well.

We are in the process of gearing our second linux server. More (boring) information to come.

It has been awefully quiet at BluHelix, and I appologize.  Lots and lots of things have been creeping into my to-do list but only a handfull of things are actually progressing at the moment.

Among the changes I’m tossing around are a number of site upgrades, including a overhall of the sub-domain mechanics (consolidation and streamlining, with a possible extension to allow users to access their own settings!), as well as, duh duh duh, WordPress integration.  Ben at http://benford.bluhelix.com/ has successfully deployed a WordPress engine already on the Czin server and I have been considering doing the same.  This would do away with the sometimes clunky forum integration and ease the transition to phpBB3.  I’m not sure if there would be any historical postings.  Perhaps there will.  Anyway this might be a long ways off, but it’s something on the list.

Also on the list – Kevin has given me a copy of RPG Maker XP that is Vista compatible!  The question is: Resurrect my current project or start anew.  It’s a question I’m continuously debating and would like to hear feedback on.  My former project made the increadible milestone of 50% maps complete (which is not to be confused with 50% complete).  Any thoughts?  If this spurs interest I might post the old projects page on this from last year.  Currently, only the screen shots are accessible.

The next item on the agenda is regarding the eventual update to this web site. Yup, if you have not already heard, I am going to update the BluHelix Studios web site soon (TM). But while this is still in the drafting stage I wanted to pose a question to you, my one (more?) reader. Is the calendar useful at all? Has anyone actually browsed to it? The calendar used to be tied into my front page and show a “what’s coming up this week” box. Unfortunately the script for the box was buggy and so I disabled it, but the calendar remains functional. Anyway, I see three possibilities:

1. Keep the same calendar system, with possible code upgrades
2. Ditch the custom calendar and tie in a professional web-based one, either an open source PHP solution or a Google integration.
3. Forget the calendar entirely.

Note that I don’t expect option 2 to be difficult – we’d just lose the single-sign-in model.

Please post comments in the forum. I would make a poll but I fear I just don’t have the visitor base for it!

XHTML.

What? Hold it! But you thought BluHelix Studios already used XHTML! Isn’t there a DOCTYPE right now for XHTML 1.0 Transitional?

Well, yes and no. See, there is a dirty little secret to many of the WWW’s XHTML web sites: they are really serving your browsers malformed, error-inducing HTML documents. The errors, of course, are simply XHTML tags that the HTML parser is choking on because they are not part of the HTML specification. You see, the XHTML DOCTYPE is only used when validated a page (and for setting IE in compliance mode), it is really the MIME type of application/xhtml+xml and the many variants that define an XHTML document.

The reason why these “real” XHTML documents are so rarely served is because the most popular browser in the world is not equipped to parse XHTML documents. IE7 is at least slightly better. Previous versions wouldn’t have a clue what to do with the non text/html MIME type and would spawn a download prompt as if you were trying to download a ZIP, EXE, etc. IE7 will successfully display the page – but using its HTML parser.

Other popular browsers like Firefox, Opera, and Safari are equipped with XML parsers.

So, at first it might seem that serving “real” XHTML documents means alienating 85%-90% of your user base. Luckily there is a technique to, literally, get both worlds. The solution: content negotiation.

Content negotiation is the process whereby the user agent (your browser in most cases) communicates to the server informing it of the technologies it understands and even which ones it prefers. The server responds by sending it content in the format the user agent prefers. This is actually a really cool idea, and if you read up on XHTML 2.0 it appears that this kind of handshaking will eventually be integrated into the technology itself and be very trivial to do. But for now we must resort to scripting.

There are two approaches to this: setting up those super-rad Apache/IIS URL rewriting to serve the content most appropriate for the requesting user agent. Or, this functionality can be done through server-side scripts. I chose the latter and coded up a PHP class to preform XHTML/HTML content negotiating. This script is pretty easy to use and preforms about a dozen regular expressions on the output buffer in an attempt to transform markup to XHTML and HTML, depending on the needs of the requesting user agent.

The usage is simple. Just instantiate the class by giving the constructor the type of document you would prefer to transmit, then add style sheets to the class, call the pro log method just before content output, call the style sheet method inside the head tag, and call the finalize method at the bottom of the page. Done.

I commented both the script and test file for your convenience. You may download the script here.

This is not the only application of content negotiation. Another common use is to chose between PNG and GIF images, depending on the capabilities of the user agent.

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.