Page MenuHomePhabricator

[WWW] Use https instead of http to fix page problems
Needs ReviewPublic

Authored by jdoerfert on Aug 25 2018, 1:46 AM.

Details

Reviewers
tonic
Summary

The webpage seems to support https:// by now but we only changed some of the links.

This is the reason why (for me) some pages are not working properly. E.g.,
I get no css here "https://llvm.org/foundation/" because of:
Blocked loading mixed active content “http://llvm.org/llvm.css
[explained here: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content]

This patch would change all leftover http addresses to https, basically the result of:

replace 'http://llvm.org/' 'https://llvm.org/'

Are there objections or reasons not to do this?

Diff Detail

Event Timeline

jdoerfert created this revision.Aug 25 2018, 1:46 AM
kpn added a subscriber: kpn.Aug 27 2018, 7:07 AM

Is there a good reason to have the hostname in the URL? Why not just link to "/Users.html" instead of "https://llvm.org/Users.html", for example? Using the hostname is only needed when linking to a page on a different server.

In D51255#1214403, @kpn wrote:

Is there a good reason to have the hostname in the URL? Why not just link to "/Users.html" instead of "https://llvm.org/Users.html", for example? Using the hostname is only needed when linking to a page on a different server.

Good point, for which I cannot give you a good answer.
I'm not really involved with the web page but just noticed that some pages are broken due to the http vs https difference.
Since removing the hostnames should solve the problem too, I am in favor.
However, I do not know if this would entail other complications so I initially chose a "somewhat safe" solution.

asl added a subscriber: asl.Aug 27 2018, 7:16 AM

I think we need to preserve the protocol. E.g. if the page is loaded via http we need to load css via http as well.

In D51255#1214424, @asl wrote:

I think we need to preserve the protocol. E.g. if the page is loaded via http we need to load css via http as well.

That sounds reasonable and is (afaik) implied by removing the hostname.
As mentioned before, I like the solution but I just don't know if that might cause problems somewhere else.

kpn added a comment.Aug 27 2018, 7:30 AM
In D51255#1214424, @asl wrote:

I think we need to preserve the protocol. E.g. if the page is loaded via http we need to load css via http as well.

That sounds reasonable and is (afaik) implied by removing the hostname.
As mentioned before, I like the solution but I just don't know if that might cause problems somewhere else.

Correct, removing the method and hostname "unmixes" the content so http loads stay http and https loads stay https.

My guess is that full URLs were used because the person doing so didn't have much experience hand coding web pages. Or maybe multiple web servers were used back then and have been consolidated since.

My guess is that at this point in history the software still in use has been updated to deal with both full and partial URLs. But I don't spend any time at all running llvm.org's infrastructure, so I can't sign off myself.

jdoerfert updated this revision to Diff 162696.Aug 27 2018, 9:52 AM

Use relative links where possible (thus if we stay in the same subdomain http{,s}://llvm.org/.*)

For subprojects, which have their own subdomain, e.g., lld.llvm.org, we modify the locations of
links (href) based on the currently used protocol. This is done through a javascript snippet in the footer.
If javascript is disabled we now default to https.

First off, thanks for offering to help make the website work correctly! This all looks pretty reasonable to me. I'm wondering though, would it be possible to break this patch up into a few smaller patches? Since we do not have any type of staging infrastructure for llvm.org, I would prefer we not change so many files all at once. I feel like three steps here might be appropriate:

  1. Try with one file (one of the files with a one or two line change) to ensure the changes work as we expect them to.
  2. Apply changes to the rest of the files with the exception of footer.incl.
  3. Apply the last patch to footer.incl which adds the javascript bits in the footer (my experience tells me this is the most likely to break something, though the JS you have provided LGTM).

Thanks,
Mike

First off, thanks for offering to help make the website work correctly! This all looks pretty reasonable to me. I'm wondering though, would it be possible to break this patch up into a few smaller patches? Since we do not have any type of staging infrastructure for llvm.org, I would prefer we not change so many files all at once. I feel like three steps here might be appropriate:

  1. Try with one file (one of the files with a one or two line change) to ensure the changes work as we expect them to.
  2. Apply changes to the rest of the files with the exception of footer.incl.
  3. Apply the last patch to footer.incl which adds the javascript bits in the footer (my experience tells me this is the most likely to break something, though the JS you have provided LGTM).

Sounds good, so let's do this step by step. [I started already since nobody found a general problem with the proposed changes.]

First some localized "absolute -> relative link" adjustments:
r341195. changed foundation/index.html to use relative links. It works for me and I'm waiting to see if it doesn't for anybody else.
r341196. changed a small part of the EuroLLVM 2017 dev meeting page. This helped, but this page is not completely working because the embedded js constructs a new css address (I think). I'm looking into this.

I'll wait a bit and if nobody complains I'll continue with the relative link adjustment. Then I'll update the patch again
and we can begin phase two.