Must play with this HTTP server/load-balancer/mail proxy/bundle of awesome sometime soon. Looks like a pretty awesome option for VPS environments and other places where there isn’t heaps of spare resources going around! My cupboard-bound SSH oasis and occasional webserver is, of course, a likely candidate… but I’m a tad concerned I’ll screw myself over with PHP. Not because it particularly gets used for that (there’s like… a few wikis and a handful of lines of PHP code easily replaced by something else that get semi-regular attention) but mostly for the “just in case” I wanna test run something. And yeah, I know, that’s what virtualised stuff should be for… but I still haven’t quite caught up to that. I’ve got an Ubuntu thing running in a virtual PC instance on the computer I use most of the time, but it just doesn’t cut it for actually trying to test something out with, you know, other users and real Internet connectivity. In other news, can-we-have-IPv6-moar-plx? Just because it’s absurd to have to pay more to run real SSL on dedicated IPs when there is SO MUCH SPACE just waiting for us to broaden our horizons and start to fill it. I’m not heaps fussed if pre-Windows XP users can’t use it, actually, because they’ve likely got bigger security problems on their hands from their network-connected 10-year-old OS than any regular web interaction is likely to give them, properly secured or not — that is, even if their web traffic is secured, their desktop is probably a botnet zombie with keyloggers and trojans abounding.
Nginx
| No Comments »
Subclipse Proxy problems
Finally, Subversion’s PROPFIND is enabled on the proxy server at one place I work, but for some reason Subclipse was still being a little bit special.
Turns out it doesn’t use Eclipse’s HTTP Proxy settings, but needs setting elsewhere.
On Windows XP, this will be in your Application Data path under Subversion. Mine is as follows:
C:\Documents and Settings\joshs\Application Data\Subversion
I haven’t got a Vista machine to test on, but it will still be the Application Data\Subversion folder within the user’s path. (I will confirm this next time I’m on a Vista box.)
Linux users, look in ~/.subversion/
Open the file “servers” (no extension) and scroll to the bottom section, [Global].
Un-comment and edit the http-proxy-host and http-proxy-port settings (and user/password if required, it wasn’t for me) as appropriate and everything will start working. You don’t even need to reload Eclipse.
Productivity just soared!
| 11 Comments »
3GB/month broken
Well, turns out last month’s HTTP bandwidth usage wound up at around 3.75GB. Coolness. It recently occurred to me that I don’t particularly have any “Slashdot-me” ambitions for this blog at present, but it’s still fun watching the numbers increase every month for no apparent reason! Except, perhaps, ‘the plebs’ catching up with my occasional open-source trendiness ;-) Or something… probably more of the ‘something’. Heh.
120,000 hits and nearly 7,500 unique visitors to this site last month were served 56,000 pages by Dale’s metro FreeBSD server… heh, from one of the most serious-looking home server setups I know of. Still, ‘consumer-grade’ though it may be, it’s doing rather well! Technology is fun ;-)
The Single IE Linebreak Through [optionally transparent] Proxy Character Encoding Bug
It’s new, so far as I’m aware, and I can’t even build a decent test case for it. In one instance alone, if there’s a blank line between two elements (i.e. just for readability, doesn’t need to be like that), then certain versions of IE — and only when their traffic is being proxied through certain transparent/non-transparent servers — will display a blanking/“unknown” character.
At first it was thought this was just because of a dud character in a file, but then we tried using PHP to echo \n\r, \n, and \r in the place of a manually entered return: all of which resulted in the bug persisting. The only fix I’ve got is to use an HTML comment between lines
</element><!-- --><another element='element'>
Like that. Anything else, and we get a blanking character in there. Bizarre!
It doesn’t occur anywhere else on the site in question, and I’m not going to waste hours trying to build another un-branded test case which may or may not work! The problem affects IE only (though we didn’t do version testing), and only when traffic is going through (some) proxy servers. And only that one character.
It’s not an encoding problem per-se, though is obviously related to that in some sense. This is still internal-only, and it’s not being dished up with proper content-types defined in HTTP headers (because I’m still liable to change my mind as to how that should be done, and I’m not calling it until the site is about to launch/what is/isn’t required in terms of content-type – affected things is abundantly clear!), but seeing as it only has an impact when using through a proxy it’s pretty obvious it’s not JUST here. Shrug. I reluctantly deleted the linebreak and the box went away.
VirtualHost, mod_proxy, and Apache HTTP 2.0 documentation
I had to setup a virtual host that proxied through to another server today, and found the Apache 2.0 documentation on that matter particularly unhelpful for a rather trivial reason.
Here’s their broken version:
<VirtualHost *:*>
ProxyPreserveHost On
ProxyPass / http://192.168.111.2
ProxyPassReverse / http://192.168.111.2/
ServerName hostname.example.com
</VirtualHost>
Here’s my working version:
<VirtualHost *:*>
ProxyPreserveHost On
ProxyPass / http://192.168.111.2/
ProxyPassReverse / http://192.168.111.2/
ServerName hostname.example.com
</VirtualHost>
Spot the difference.
Yes, it was as simple as an omitted trailing slash.
Only takes a minute or two to figure out what’s going wrong, but it’s pretty darn annoying for that minute: I assume, as would many people, that documentation is generally infallible — its purpose being the cure to various software ailments, not the cause! Ah well. I’d have edited the Apache documentation, but it’s not a wiki and I can’t be bothered joining whatever mailing list I’d have to join to get one character added to their site!
Posting from BloGTK 1.1
Just for kicks, to see if it’s any easier than using a plain old web browser to interface with the blog!
Anyway, BloGTK is a desktop client for WordPress which runs on Linux systems. Niggly features I’ve discovered in the last 30 seconds:
- Can’t select text, then click the “hyperlink” icon, and have the anchor tags wrap around selected text — they appear to the right of it.
- Compulsory “target” field in anchor generation — which I don’t think (if I recall correctly) is even valid in XHTML 1.1, possibly earlier.
- Lack of built-in quick tags that WordPress’ own posting interface has, namely for unordered lists, list items, and tagging of abbreviations, etc.
- Ironically, it’s possible to define your own tags, which can wrap around selected text just fine, whilst the “built-in” anchor button doesn’t do this… Hmm, okay.
It’s really little things, nothing major — the formatting tags (strong, em, etc.) work just fine on selections, which is great. It also has an inbuilt preview which (I’m 99% sure) functions using an internal rendering engine (or part of the GTK toolkit, same thing), rather than making HTTP calls. A change that’d be interesting to see (although one which doesn’t affect me directly) would be the implementation of either a WYSIWYG editor, or simply Textile or Markdown support with XMLHttpRequest being used (or something like it? I gather that’s a JavaScript thing, not having ever used it, so it mayn’t be usable like that.
Another thing that’d be nice is the implementation of keyboard shortcuts, just for text formatting stuff — so, Ctrl + B for strong and em tags, etc. And also the changing of the category display to a list of checkboxes in its own frame (or whatever the term is in desktop app interface design lingo) on the right of the posting area, instead of a dropdown — that’d allow posters to select multiple categories, more rapidly.
It’s a good simple app (sorry… I know it’s probably rather unsimple when you look at the code driving behind it, but I don’t understand any of that Python stuff, so I’m just judging on the interface), but a few niggly things mean I’d still prefer to use the native WordPress web interface.
Edit: In part to see if it does, but also because I had another thought — the absence of a “Posting…” status window is also something which could be improved, just so the user doesn’t think the application has crashed. It took a while here due to my ISP’s poor DNS performance, and had I not known why it was going slowly, I may have closed the application thinking it had crashed.
| 1 Comment »

Recent Comments