As QRZ approaches its 16th anniversary of continuous service online, it should come as no surprise that we've got a virtual three car garage full of old junk lying around that is in serious need of a cleanup. While we don't have any of our original 1993 software and files laying about, we do have plenty of files, links, and programs that no longer serve a useful purpose. Worse yet, there are some items which are still in limited use that really need to go away.
This collection of junk files and links exist primarily because every time we've made a change or an upgrade, we kept a copy of the old files around, 'just in case'. There is something frightening about deleting old files because you never know when you might need them again, or, perhaps they contain some tidbit of information that you've forgotten about. Still, after several generations, there exists a growing collection of cruft that is undeniably deprecated and keeping it around actually becomes a liability.
Getting rid of old programs and files is pretty easy. Getting rid of some of the older links, while easy to do, can cause some unexpected behavior that isn't immediately apparent.
Case in point:
Linking to Specific Callsign Pages on QRZ
Over the years there have been several different web page links to reach personal callsign pages on QRZ. Starting with
http://www.qrz.com/... and ending with a variety of names including, but not limited to: directory.cgi, cbook, call=, lookup, and many others. A few of years ago, we had a
bright idea and configured our web server to recognize unqualified callsign lookups such as
http://www.qrz.com/(your_callsign). This shortcut was very convenient but it caused a lot of trouble both in the foreground (user confusion) and in the background, behind the scenes on our server.
In January 2009 we formally introduced QRZ 2.0 and it has been a great success. The web page address prefix for callsigns under QRZ 2.0 is
/db/ as in
http://www.qrz.com/db/(your_callsign)
We documented this link prefix when QRZ 2.0 was introduced at the
Linking To QRZ page.
One thing that the
Linking to QRZ page does not describe is the older method of unqualified linking as described earlier. That's because we already knew back then that the unqualified links were technically a bad idea. After 9 months of successful operations under the new '/db/' qualifier, it's time to get serious about adopting the standard as a firm rule.
So, effective immediately, direct, unqualified links to callsigns on QRZ.com will no longer be supported. Before you get angry about the change, note that it's only three more characters (e.g. 'db/') than doing it the 'lazy' way, and it improves the web site as a result.
In the following paragraphs, I'll explain a bit more in technical detail about why this needs to be done.
A web server can serve an unlimited number of pages, each having almost any conceivable name. Typically, when a user requests a specific page, the server locates the file for that page and sends it to the user. Some services, like QRZ, have so many possible pages that instead of storing a file for each page, the pages are generated dynamically, (on-the-fly) upon request.
As our site became more complex, we developed a number of server programs to serve specific requests. Which program handles which request is governed, in part, by what appears in the part of the URL that follows
http://www.qrz.com/... For example, if the next part after the URL is /db/, then it's a callsign database lookup. If it's /i/ then it's an include-page. /li/ is used for Login and /lo/ for logout, and so on.
Each of these URL prefixes (or suffixes, if you will), creates a
namespace within the server that starts to get quite complex. So, the question is, if the server action is determined by what follows the ..com/ in the address, then what do we do with something like ../ZZ1ZZZ (a callsign) ?
Well, the server trick we used was to tell it, "in the absence of any defined prefix", or, "if a file by this name couldn't be found...", then "pass it to the /db/ lookup routine".
While this works for properly formatted callsigns in our database, it leaves a trail of debris that can be truly confusing. The first thing we see is a message in our server Error Log that says "... file not found.. ZZ1ZZZ". Not just once, but literally thousands of times per day. Our server logs grow to astonishing sizes, hundreds of megabytes, in no time. Note, this isn't technically an error because subsequent processing did locate the callsign, but, there is still the issue of cleanup. This backdoor cross reference doesn't come cheap, either, as it increases the server load by 2X of what is should have been for the request.
The second problem, which contributes to a user confusion and sometimes astonishment, is that a mistyped page name will give you completely unexpected results. An example of this might misspelling 'index.html' in the address. You type in
http://www.qrz.com/indez.html and what you get is a message that 'INDEZ.HTML does not appear to be a valid callsign'! The same is true for virtually any mistyping whatsoever: I gets reinterpreted as a possible callsign, with results usually having no relevance whatsoever.
So, with the negative performance implications along with the confusing and irrelevant error responses, it's a clear indication that we need to stop doing this for everybody's benefit.
We apologize in advance for any inconvenience this may cause our users. Whether it amounts to an update to your bookmarks, or, changing the content on your own web page, rest assured that at a minimum, QRZ will at the very least, will take you to our home page and/or other links that lead to what you're probably looking for.
Please help us embrace the /db/ addressing scheme and many thanks to those of you who have already read the docs and have adopted the correct methodology.
73, -fred
.
We appreciate your support.
QRZ Website Link Policy Update
Ham Radio Deluxe
Linear Mode
