Joe Teti, Dual Survivor, Military Service and Honor.

Attribution: By Regargia (Own work) [CC BY-SA 4.0 (], via Wikimedia Commons
I’m a retired webmaster, having worked for many moons in the spacecraft and propulsion business. Life for me is a lot easier and I’ve begun training myself for more outdoor activities including bushcrafting for fun and potentially even perhaps some career options down the road. I love the outdoors, having spent much time in it as a kid and although I couldn’t join the military due to my physical health, I have had a great affinity and respect for our military throughout my life. Without them, this nation would be no more.

One of my favorite shows on survival was Discovery Channel’s Dual Survival and my all time favorite host was Joe Teti. For about 2 years, Joe was the unabashed star of the series along with Matt Graham and it saddened me to hear about Joe suddenly departing the series after a mysterious series of posts appeared accusing him supposedly killing a dog on a production set. I researched further into this event and the rumor was that Joe intervened to stop a cat from being killed. The media made much fodder off of this and left the clear implication that Joe was some kind of mad killer and he was given the boot as the articles and web forums blazed with news of all of this.

I put very little stock in any of these reports. And I note with great empathy to all public figures that they become targets the minute they achieve any measure of fame. I look at the dog killing story with a critical eye and even if Joe had done this, not a single news outlet has made any mention about Joe coming to the rescue of the cat! If the story holds water, then one can in all fairness see a man who was attempting to do something noble and it went awry. My suspicions are that there is FAR more to these tales than meets the eye and that a lot of these claims  are complete hooey.

I was also aware, even in mid-2015 of allegations that Joe was not the soldier he claimed to be and as of this writing in 2018, I’ve seen enough articles with proof of his military service to indicate that Joe has been more than true to his word of his veteran’s status and his combat record. I will provide links to some of the material I found later in this article, but I want to address the question of the terrible thing about fame that I call “The Green Eyed Monster”.

Jealousy is a pretty nasty creature. And it can cause people to say and do all sorts of terrible things to assuage the slights people feel they must address in order to achieve their goal of feeling vindicated. Without naming names, I can only say that it’s a sad thing to see these same people’s names over and over again, attacking Mr. Teti while he himself remains silent, other than the few positive comments he’s given the public since his exit from Dual Survival. It is 2018 and these folks are STILL at it. Give it a rest guys… Joe’s silence is speaking clearly and at much louder volume that all of the posts you continue to put out in chat forums, YouTube and other social media. Put your energy into positive things like survival teaching and character development.

Joe’s record is pretty interesting since it shows he did service in the Marines as well as the National Guard Special Forces as well as doing contractor work that was an extension of his military career. I believe him when he says that he cannot comment on the nature of his work in the field for his contracting work and it is pretty clear he was doing what he claims to have done. There are some who claim he is no veteran but Discovery Channel had earlier assured everyone they HAD vetted him and that he was the real deal. So it is pretty clear he’s been through the ringer being examined and I’d bet good money on his claims.

I have never met or talked with Joe, but if I could meet in person, I’d shake his hand and ask to sit and listen to his side of the story. He’s been denied a forum from which to speak for years and my only gentle observation for him is that perhaps the time has come to speak up, do some media work and even write a book about the good things that happened and to ignore all the negative noise.

Joe – You deserve to be heard Brother. I hope to hear your side of it since we’ve all heard from the other side is unrelenting fury and anger for 4 or 5 years now… People still care Joe. God Bless and take care.

Links of interest:

Surv Tac 7 Knife





Update on Apache NonSSL and Share Servers Solution

Some months ago, I wrote an article on the difficulties I was having due to my hosting an SSL site on a shared provider server using a single SSL site to host multiple domains belonging to many different customers. Visit this LINK to get the details.

I coined my own term of “Jekyll and Hyde SSL Bug” to describe the issue with these shared servers and the SSL problems that occur on hosted sites. This resulted in a new web site to document the problem in further detail, calling out the industry and Apache for having created this issue in the first place.

The upshot is that while my first solution works for preventing my site from being visited by different domain URLs, it does not completely solve the problem of different indexing engines from cataloging content, effectively bypassing my solution. I was still seeing my site pages showing up on some sites and theorized that index engines may be able to index content even with the SSL mismatch in place.  My original solution had solved MOST of the issues, but not all of them.

The content snapshot below illustrates the continuing issue:




Again – to reiterate: My theory is that Google and other search engines may completely ignore SSL mismatch warnings and index the content irrespective of the mismatch. That is unfortunate and illustrates yet another potential problem in how the web indexes things. I’m not completely sure this is a fact, but I realized that a solution might be in order if I could tell .htaccess to use an alternate robots.txt file for domains that were not my own!  I came up with the following .htaccess code to solve the issue:

# Prevent robots.txt execution from unwanted domains from indexing. This should remove any sites from indexing by telling the relevant servers to stop  indexing anything OTHER than afterburner1.  – Rule installed 3/8/2018 – check again in one-quarter to check results.
RewriteCond %{HTTP_HOST} !^(www\.)?afterburner1\.com
RewriteRule .* noindex-afterburner.txt [L]

I created the noindex-afterburner.txt file and populated it with the following:

User-agent: *
Disallow: /

Voila! I tested the site and all appears well. Now to wait on things and how it goes.

I’ll report on how well this works and if the indexing issues disappear over the next few months, I’ll consider this a final success.

Apache SSL and Share Servers problem with nonssl sites

Last October, I ran into a pretty big set of problems with all of my web sites and this necessitated a complete re-think of my site layout and methods of publishing content.

During this process my entire site was moved to a new IP address and my existing SSL site here on Afterburner1 made the journey with no troubles… Or so I thought.

I am pretty careful about analyzing my logs and I noticed a sharp uptick in traffic and after a few weeks, I realized that there was a problem. I couldn’t figure out what was causing all these visits to my site and they were all very short visits.

I suspected spammers and tried a few things to no avail. And then, quite by accident, I discovered that my site content was showing up on all sorts of web sites, coincidentally ALL with the same IP address my site  has when doing an nslookup on them.

As you can see below, my content was showing up on sites that had nothing to  do with mine. I coined the term “ghost content” since the page were NOT being hosted with this content. It was only showing up on Google.

What I discovered was that my provider had the issue (and it seems to be a common theme with many other hosting providers as well). It seems that the shared servers like the one I reside on, host more than one client, all off a single I.P. address. And while this is quite normal, what was NOT normal was that I had an SSL certificate that was the first one on the list of sites for that particular server.

My provider decided to tell me after some days of prodding as to what the cause was. It seems that if an web site does NOT use SSL certificates on a shared server, then anytime someone or something like a search engine visits that site with then they get directed to the alphabetically first VALID SSL site on the shared server. In this case, it was MY site – This site you are on.

And the fun wasn’t over. My provider informed me this morning that the ONLY way to fix this was to have me shell out $24 to go to a separate IP address on my OWN server. I was more than angry at this exchange because it meant that I would leave the server to solve MY problem and it would be dumped on someone else and the cycle would continue.

I grumbled about it and then decided to tell them to go fly a kite. And I decided to think through the problem. After running some tests, it occurred to me that when visiting one of these site on the same server as me and then using https to get to their URL, that I was able to see their hostname when it got dumped into my site root.

So, I went and made a new domain at and created a landing page with information about the problem. But I needed to do something in .htaccess and decided to fail ALL https requests to my site that did NOT use my domain.

I created the following rule to be placed in my site .htaccess file:

# Send all hosts that do NOT match my address to the purgatory where they belong
# This is done because my SSL cert is the first one on the shared server. So,
# These people will be sent to the page.
RewriteCond %{HTTP_HOST} !^(www\.)?afterburner1\.com [NC]
# Return a failed request and tell the source that the content is gone "G"
RewriteRule .* - [F,G]

So, after some work to make it all work as intended, I released the code and voila! Any http host on my shared server whose site is visited with https is rewarded with a failure to connect to the page via error code 410 as a result of the RewriteRule I installed.

Note: As of March 2018, I realized I needed to add some additional code. Visit this page to see the new additions.

To learn more, visit  and if you happen to be on a shared server and are seeing the same issues I was having, you now know what to do! Contact me if you have any questions!

— Jon