Mozilla サポートの検索

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

詳しく学ぶ

このスレッドはアーカイブに保管されました。 必要であれば新たに質問してください。

Outgoing http links from deviantArt incorrectly go to https

more options

In Firefox, clicking outgoing links on the deviantArt web site -- https://www.deviantart.com -- to http protocol sites instead go to the equivalent https site--and fail, if there is no https site. This error occurs in Firefox, but not in Chrome or Edge. And it does not occur in Firefox if you copy and paste the link, rather than clicking it directly.

For instance, the artwork description on this page

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

includes an outgoing link with the URL

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

If you copy and paste that link off of the deviantArt page and into Firefox's navigation bar, it correctly goes to deviantArt's redirect page, and clicking the link there takes you to the specified page on http://smbhax.com site, http://smbhax.com/?e=0036&d=0024 .

However, if you directly click that same outgoing link in the description on https://www.deviantart.com/smbhax/art/Visual-792896874 , no redirect page appears, and the browser ends up showing an incorrect, https address in the nav bar

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

while displaying an error page saying

"Unable to connect

Firefox can’t establish a connection to the server at smbhax.com."

Firefox should not be attempting to go to the https address, as the link specified through deviantArt's redirect is an http address. I don't *think* this is an error with dA's redirect function; as I mentioned, clicking the outgoing links goes to the http site properly in Chrome and Edge, and copying and pasting the outgoing link into Firefox's navigation bar, instead of clicking on it directly, works correctly. I contacted dA's support and they suggested it was a browser issue. However, it is possible that Chrome and Edge are invisibly redirecting the failed https request to http--although I would think that in that case they would at least prompt the user, but I really have no idea.

I created a new Firefox profile, changed no settings, and the problem of clicking the link from dA and being taken to the https site instead of the specified http site still occurred.

In Firefox, clicking outgoing links on the deviantArt web site -- https://www.deviantart.com -- to http protocol sites instead go to the equivalent https site--and fail, if there is no https site. This error occurs in Firefox, but not in Chrome or Edge. And it does not occur in Firefox if you copy and paste the link, rather than clicking it directly. For instance, the artwork description on this page https://www.deviantart.com/smbhax/art/Visual-792896874 includes an outgoing link with the URL https://www.deviantart.com/users/outgoing?http://smbhax.com/?e=0036&d=0024 If you copy and paste that link off of the deviantArt page and into Firefox's navigation bar, it correctly goes to deviantArt's redirect page, and clicking the link there takes you to the specified page on http://smbhax.com site, http://smbhax.com/?e=0036&d=0024 . However, if you directly click that same outgoing link in the description on https://www.deviantart.com/smbhax/art/Visual-792896874 , no redirect page appears, and the browser ends up showing an incorrect, https address in the nav bar https://smbhax.com/?e=0036&d=0024 while displaying an error page saying "Unable to connect Firefox can’t establish a connection to the server at smbhax.com." Firefox should not be attempting to go to the https address, as the link specified through deviantArt's redirect is an http address. I don't *think* this is an error with dA's redirect function; as I mentioned, clicking the outgoing links goes to the http site properly in Chrome and Edge, and copying and pasting the outgoing link into Firefox's navigation bar, instead of clicking on it directly, works correctly. I contacted dA's support and they suggested it was a browser issue. However, it is possible that Chrome and Edge are invisibly redirecting the failed https request to http--although I would think that in that case they would at least prompt the user, but I really have no idea. I created a new Firefox profile, changed no settings, and the problem of clicking the link from dA and being taken to the https site instead of the specified http site still occurred.

すべての返信 (16)

more options

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.

more options

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.

この投稿は jscher2000 - Support Volunteer により に変更されました

more options

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.

more options

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.

more options

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.

more options

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?

more options

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."

more options

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?

more options

(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.)

more options

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

more options

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.

more options

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

more options

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.

more options

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.

more options

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

more options

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