I was revisiting the validation of domain names and realised that most of the regexes posted around the web have faults.
Many refer to Sean Inman’s 2006 post, which does a fair job but is prone to break as new TLDs are introduced. This answer on StackOverflow is about the best I’ve found so far: it enforces label and overall lengths; allowing multiple dashes means it works with punycoded domains; it’s generally permissive so won’t break as TLDs change, but there’s one case not handled. RFC2872 says that labels that are not used as hostnames (i.e. which do not map to an IP, for example in TXT or SRV records) may contain any printable ASCII character, so `_,;:'”!@£~$` and friends are all up for inclusion. This is most commonly found in domainkeys, which use the `_domainkey` label. There’s a good article on the use of underscores in DNS.
This does relate to the validation of email addresses (which often contain domains), and the best page on that subject is this one, however, you can’t simply extract the domain part from that as domain names in general are a superset of what’s used in email.
It’s difficult to do this right because you can’t tell whether a label is a hostname or not, or where a hostname stops and a domain begins, and validity varies according to context: `_domainkey.example.com` is invalid in an A record, but valid in a TXT record. I can foresee a parameter to allow you to specify usage context to deal with this. It might be better to process the name backwards so that you have more context available as you encounter each label, for example if you processed `www.example.com` as `com.example.www`, you would stand a better chance of knowing whether www is a hostname or a domain name.
I’m mainly thinking out loud here, I don’t have a solution as yet!
After many years of procrastination, I’ve finally migrated my blog from Serendipity to WordPress, including importing all my old posts, and translating a bunch of metadata so that old URLs still work. I’ve been meaning to do this for ages, but what set me off today was spotting the lovely Twitter Bootstrap 2.0 Theme by 320press, so thanks to them for providing a) a nice theme, and b) motivation!
I went back and reformatted the old code markup using some new plugins (there are an awful lot of bad WP plugins!), found a couple of unapproved comments, broken links and other cleaning up. This should last me for a while.
It’s been thoroughly documented that Mac Skype 5 is an utter piece of junk, but it just keeps getting ‘better’!
Today it informed me that there had been a minor update to the current beta release (5.4).
Being wary of what Skype considers an ‘upgrade’, I clicked the ‘what’s new’ button that it offered to see the changes. This took me to a page all about Skype 5.3, with no hint or link of any release notes. A bit of googling for the new version number led me to some release notes. I thought this sounded fair enough, so clicked ‘update’. It downloaded the new version like this:
but then presented me with this:
That’s a very strange error. It’s telling me that it accidentally downloaded the wrong version, and didn’t check that it was the right one, it just assumed it was. Doesn’t bode well for security. On top of that the reason it can’t install is because it’s not fat enough?? Are they trying to suggest that code bloat is mandatory? Clicking ‘Manual update’ took me to the Skype 5.3 page again. Sigh.
To their credit, this IS a beta version, but given that only bug fix mentioned for the last 2 months work on this release is “Skypenames ending with period do not work properly”, I’m not holding my breath for a stable release.
Skype used to be a beautiful (well…), elegant, Mac-like app. It’s now a pig in a dress. With lipstick.
MacPorts told me that there had been a subversion update (1.7.1), which I went ahead and installed. Woo! Huge speed improvements for everything I tried with the CLI client, great stuff. A short time later my IDE (PHPStorm) fell over screaming. It doesn’t like 1.7 yet, and it’s a bit stuck until SVNKit supports it. I should have checked really.
So how to downgrade? Fortunately this post makes it very easy. So I just did:
sudo port deactivate subversion @1.7.0_1
sudo port activate subversion @1.6.17_1
But now I’m stuck with a working copy in 1.7 format with uncommitted changes, and there is no tool to convert it back to 1.6 format. This is easily worked around; check out a new working copy (using svn 1.6) and sync across the changes, ignoring the .svn folders, like this:
rsync -av --update --exclude=".svn/***" ~/Sites/myproject1.7/ ~/Sites/myproject1.6
All happy now.