Server Accessibility
August 22nd, 2008
No our server is not dying. But my IP updater is. I am working on it.
Archive
Archive for the ‘Inside BluHelix’ Category
Of WordPress and RPG’s
February 14th, 2008
Hey all,
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.
Updates and… updates
November 13th, 2007
First on the updates agenda, I uploaded new versions of both my Content Negotiation class (which is renamed to Content Negotiator) and shorten_text. Very minor changes, mostly just the before-mentioned name change and I changed my double quotes back to single quotes. I had been using single quotes throughout my time at the Berglund Center and began moving to double quotes. But then I read an article saying single quotes are faster and I felt kind of foolish. I just wish the newline escape was supported. I mean seriously, that’s like the only disallowed escape sequence I ever try to use!
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:
- Keep the same calendar system, with possible code upgrades
- Ditch the custom calendar and tie in a professional web-based one, either an open source PHP solution or a Google integration.
- 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!
Content Negotiation
November 2nd, 2007
I am quietly at work planning out my re-design for BluHelix Studios. While one of my goals is to migrate to a system bearing a resemblance to the header/footer system I created for the Berglund Center sites, I have also been meaning to do something else.
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.
Living behind a proxy
November 1st, 2007
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.