QRZ Website Link Policy Update
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
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.
A no brainer, Fred. I know any programs use the old format and will require updates. But it's one of the hazards of writing software with hard links. My guess is that most would have already put your site root command name in the setup file allowing it to be changed if necessary. If not, shame on the.
KY5U - Be a REAL amateur, learn CW.
THE BIG CLEAN
That is a well-reasoned and quite reasonable request to impose upon users. All power to your elbow! Let it go forth and clean up! 73 Duncan, G1OEQ
Quite right too! There are only so many things a programmer can do to help a dumbo user!
made the change on my page
I made the change to my page, but made a slight change to the code Fred had provided on the "Linking To QRZ" page. I prefer that links to pages outside of my web page open in a new window. So, I made a slight change to the code.
I adding the target="blank" tag after the URL in the code so that it will open them in a new page.
It took about 5 minutes to change - most of that time was spent uploading the html file to my server.
I tried to actually show the code that I used, but it kept interpreting the code and putting it how it would display rather than the text of the code.
Don - KDØJBN
Previously - KCØTNJ
Visit my web page - [url]http://kd0jbn.webs.com/[/url]
St Louis and Suburban Radio Club - [url]http://www.slsrc.org/[/url]
Ham Radio Deluxe
I guess that's why my logbook entries in HRD do not work when entering a station call sign and hitting QRZ for information. It looks like Simon Brown will have to modify his program (s) again.
It's already fixed, in both the 4.x and 5.x versions.
Originally Posted by N5JDL
Just get the newest updates and you're set.
I am using a DXLAB LOUNCHER about one year... I find it very nice and easy to use.
Especialy I like options that offers PATHFINDER. Yesterday I use this option regularely, but today I can not. I do not know why, but I simply can not take data from QRZ.com in to my LOG. In a top of frame I have a call sign I am looking for, but on a second frame there is no call sign I looking for.
Message I received every time is CALL SIGN WAS NOT FOUND. When I go to QRZ web site i can find that call sign normaly.
Please, If someone can tell me how I can solv my problem???
Thank you very much!!!
Anela - E74EE
Seems other URLs not mentioned in the original post above were also deprecated. I think the 2 below were good candidates for being redirected and wouldn't suffer from the same issues described in the main post:
Maybe Fred could add the 2 above examples to his original post for those that don't read all the follow-up posts.
Besides HRD which is now patched, other utilities/programs could have been impacted. I've used what was posted at http://www.kg4zow.us/qrz.shtml to provide a QRZ callsign search from the search box in my browser and that needed to be changed as well.
David - K2DSL
Still have a problem
I tried many variations on EDX LAB Pathfinder config, but still no succsses.
Still can not take the data from CBA option.
I kindly ask for help...
Thank you very much!
Best 73 de Anela - e74ee