Okay, I see why this is happening. DeviantArt has a Content Security Policy header in the first page instructing browsers to upgrade HTTP links to HTTPS. Firefox is applying this to the redirect. I don't know whether Firefox is following web standards or misinterpreting them. Maybe I'll look that up next. Not that this fixes anything, but at least it's not a completely mystery how this occurs.

Step 1: Request the main page

GET https://www.deviantart.com/smbhax/art/Visual-792896874

Response Headers:

HTTP/2.0 200 OK content-security-policy: upgrade-insecure-requests; block-all-mixed-content;

Step 2: Requesting the outbound link

GET https://www.deviantart.com/users/outgoing?http://smbhax.com/?e=0036&d=0024

Response Headers:

HTTP/2.0 302 Found location: http://smbhax.com/?e=0036&d=0024

Step 3: Following the Redirect

Firefox Browser Console message:

Content Security Policy: Upgrading insecure request ‘http://smbhax.com/?e=0036&d=0024’ to use ‘https’

GET https://smbhax.com/?e=0036&d=0024

(Fails)

I can't think of a workaround off the top of my head other than either

(A) If you are viewing DeviantArt in a regular window, right-click the outbound link and Open Link in New Private Window; or

(B) Right-click > Copy Link Location, then paste into the address bar and load from there

The reason that works is you get the intermediate page, and it has a plain link to the external page, and external links are exempt from the HTTPS upgrade.

I couldn't find a bug on file for this at https://bugzilla.mozilla.org/ and I was thinking of filing a new one saying that when a redirect goes to a different origin, the connection should not be upgraded, but I'm not really sure what is correct. Perhaps DeviantArt should not combine the "must upgrade to secure" with links to external servers? Anyway, it's a really interesting problem.

One possible workaround would be an add-on or script that finds these links and if they are to insecure sites, modifies the link to force display of the intermediate page. For example:

var aels = document.querySelectorAll('a[href*="https://www.deviantart.com/users/outgoing?http://"]');
for (var i=0; i<aels.length; i++){
  var s='noreferrer '; 
  if(aels[i].hasAttribute('rel')){
    s+=aels[i].getAttribute('rel');
  } 
  aels[i].setAttribute('rel', s.trim());
}

Now that I think about it, perhaps it makes more sense to just turn it into a direct link. For example:

var aels = document.querySelectorAll('a[href*="https://www.deviantart.com/users/outgoing?http"]');
for (var i=0; i<aels.length; i++){
  aels[i].href = aels[i].href.replace('https://www.deviantart.com/users/outgoing?', '');
}

Yes, much simpler and faster. Except you don't want to be opening the Web Console each time, so you need a user script engine (e.g., Tampermonkey, Greasemonkey, Violentmonkey) or other tool to run the script automatically when you load the page.

I'd figured out copy and paste works. : ) Good find about the Content Security Policy! Firefox seems to be handling it differently than the other browsers. I wonder if it's supposed to be doing that.

deviantArt's policy statement on upgrading to https https://www.deviantart.com/danlev/journal/DeviantArt-Is-Switching-To-HTTPS-697996906 makes clear that they wanted to force externally served images to use https; not so sure they meant to break outgoing http links, though--the support team suggested maybe the error was just the browser's "warning" when it found the user being redirected to an unencrypted site. Definitely reads like an error rather than a warning, though, especially as there's no way to accept and click through to the intended destination.

My concern about this is not for my own use of the links, but for other dA users who might be trying to use my links, and get tripped up by the http to https upgrade if they're running Firefox. In Googling this I found another dA user who had the same concern for viewers about links she was putting on her pieces.

There is a 16-month-old bug on file, and I added a reference to this thread: https://bugzilla.mozilla.org/show_bug.cgi?id=1422284

It generally doesn't help to add comments like "hurry up" and "are we there yet," but if you hear of other popular sites affected by this issue, we could add them to try to get it fixed sooner.

Wonderful! Since there is a bug entry on the underlying problem, does that mean I should mark your comment as "Solved the problem"--or do I leave the support thread open until the bug is actually squashed?

It's up to you whether to mark it. The main difference is that the post you mark as a solution appears directly below the question, and the meta data of the page is changed to allow it to come up in web searches. That could be useful, even if it is more "explained" than "solved."

Odd that open support forum "questions" aren't allowed in web searches; when I was Googling about this problem, I didn't look very hard at "Solved" results from this forum, assuming "Solved" meant "Fixed."

It does show up through searches of the support forum, at least. And there it says "1 person has this problem," which makes me lean toward wanting to leave it open.

I don't suppose it will automagically be marked as Solved when the Bugzilla entry is marked as fixed?

(I suppose if I actually phrase this entry's title as a "Question" as the forum puts it, that question could be considered solved; but when I go to edit the title, the help box that appears gives examples that *are* phrased as problems rather than questions, and refers to what to put in there as "the problem."

I guess this is the case of the original "Question" software sort of being used for a different purpose--a support forum that may deal with software bugs--than it was originally designed for.)

How can this problem be resolved so that the link goes to the intended location.

Hi ralphcpace, are you the webmaster at DeviantArt, with the power to change how the site works? If not, please check out the workarounds discussed earlier in this thread.

Another possible workaround might be to use a link shortening service like bit.ly although I don't have any personal experience with those.

I am not associated with that site - it just reflected my problem. The work arounds referred to aren't helpful since I need to make this link available to other users simply via a web site link.

Please complain to DeviantArt about this problem. As far as I can tell, there isn't a workaround for DeviantArt users other than using HTTPS links.

jscher2000 said

Another possible workaround might be to use a link shortening service like bit.ly although I don't have any personal experience with those.

The bit.ly link shortener does not work--you still end up being redirected to the nonexistent https://smbhax.com .

I put a test link for that at the end of the description in this dA piece if anyone wants to check it out: https://www.deviantart.com/smbhax/art/Kick-Ass-Magic-656978134

Hi smbhax3, thank you for testing that. Apparently the directive to use HTTPS can follow a double redirect.