openzipkin / openzipkin.github.io

content for https://zipkin.io
https://zipkin.io
Apache License 2.0
39 stars 64 forks source link

Zipkin website does not render correctly #135

Closed cebartling closed 5 years ago

cebartling commented 5 years ago

When navigating to https://zipkin.io/, only the Zipkin logo in the top left corner is rendered. The rest of the viewport is devoid of any content. There seems to be content pulled from the server, but it quickly is replaced. Both Chrome and Firefox demonstrate this issue. Here's the Javascript console from Chrome Dev Tools when initially visiting the Zipkin website:

​15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure stylesheet '<URL>'. This request has been blocked; the content must be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure stylesheet '<URL>'. This request has been blocked; the content must be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure stylesheet '<URL>'. This request has been blocked; the content must be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure stylesheet '<URL>'. This request has been blocked; the content must be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure stylesheet '<URL>'. This request has been blocked; the content must be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.091 Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure image '<URL>'. This content should also be served over HTTPS.
15:36:23.270 zipkin.io/:1 Mixed Content: The page at 'https://zipkin.io/' was loaded over HTTPS, but requested an insecure favicon 'http://zipkin.io/public/favicon.ico'. This request has been blocked; the content must be served over HTTPS.
codefromthecrypt commented 5 years ago

@abesto if you have some cycles this one looks solvable without drama (I hope I didn't jinx it!)

On Sun, Jul 21, 2019, 5:42 AM Christopher Bartling notifications@github.com wrote:

When navigating to https://zipkin.io/, only the Zipkin logo in the top left corner is rendered. The rest of the viewport is devoid of any content. There seems to be content pulled from the server, but it quickly is replaced. Both Chrome and Firefox demonstrate this issue. Here's the Javascript console from Chrome Dev Tools when initially visiting the Zipkin website:

​15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.091 Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.

15:36:23.270 zipkin.io/:1 Mixed Content: The page at 'https://zipkin.io/' was loaded over HTTPS, but requested an insecure favicon 'http://zipkin.io/public/favicon.ico'. This request has been blocked; the content must be served over HTTPS.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/openzipkin.github.io/issues/135?email_source=notifications&email_token=AAAPVV6VCG7YMGGG6JXURALQAN2ENA5CNFSM4IFPXHDKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HAOQHXQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPVVZDIT6LHNS3YUVGYTTQAN2ENANCNFSM4IFPXHDA .

abesto commented 5 years ago

Huh. Thanks for the report and mention, I'll check this out soon (tm)!

abesto commented 5 years ago

Sat down to track this down and fix it. Totally failing to reproduce. https://zipkin.io/ loads perfectly on both Chrome and Firefox for me. There are no errors in the developer console on either browser. curl https://zipkin.io | grep 'http://' confirms there are no http:// references in the served HTML.

I'm wondering if maybe this is / was some browser or CDN cache weirdness. @cebartling can you still reproduce the issue? If yes, would be great if you could

codefromthecrypt commented 5 years ago

fwiw a couple others of us were equally unable to repro. thanks for looking deeply!

On Sun, Jul 28, 2019 at 8:26 PM Zoltán Nagy notifications@github.com wrote:

Sat down to track this down and fix it. Totally failing to reproduce. https://zipkin.io/ loads perfectly on both Chrome and Firefox. There are no errors in the developer console on either browser. curl https://zipkin.io | grep 'http://' confirms there are no http:// references in the served HTML.

I'm wondering if maybe this is / was some browser or CDN cache weirdness. @cebartling can you still reproduce the issue? If yes, would be great if you could

try loading with a clear browser cache, see if the problem persists paste the output of curl -vvv https://zipkin.io into a Gist or pastebin or whatever and share it

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

cebartling commented 5 years ago

@abesto and @adriancole I’ll give it another try later today. Thanks for looking into this potential issue.

cebartling commented 5 years ago

@abesto and @adriancole I'm trying this on a different computer and still seeing the issue with https://zipkin.io.

On Safari...

Screen Shot 2019-07-29 at 11 03 06 AM

On Chrome, in an incognito window, I get the same thing, but also received a alert that some of the content is insecure. When I click the link to load the insecure content, the page renders...

Screen Shot 2019-07-29 at 11 09 37 AM

Chrome DevTools console shows warnings about mixed content:

Screen Shot 2019-07-29 at 11 12 03 AM

Hope this helps in your root cause analysis.

abesto commented 5 years ago

Thanks! That SSL cert issue could explain the errors I think. Possibly your machines don't trust the issuer of the cert we use? A paste from curl -vvv https://zipkin.io should help get closer to that.

On Mon, Jul 29, 2019 at 5:13 PM Christopher Bartling < notifications@github.com> wrote:

I'm trying this on a different computer and still seeing the issue with https://zipkin.io.

On Safari...

[image: Screen Shot 2019-07-29 at 11 03 06 AM] https://user-images.githubusercontent.com/33961/62063569-b5179600-b1f0-11e9-97d2-ec3b5430bf38.png

On Chrome, in an incognito window, I get the same thing, but also received a alert that some of the content is insecure. When I click the link to load the insecure content, the page renders...

[image: Screen Shot 2019-07-29 at 11 09 37 AM] https://user-images.githubusercontent.com/33961/62063976-8f3ec100-b1f1-11e9-833e-45eb087fdcc4.png

Chrome DevTools console shows warnings about mixed content:

[image: Screen Shot 2019-07-29 at 11 12 03 AM] https://user-images.githubusercontent.com/33961/62064107-c9a85e00-b1f1-11e9-8902-874f92c78f36.png

Hope this helps in your root cause analysis.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openzipkin/openzipkin.github.io/issues/135?email_source=notifications&email_token=AAAOUTUBDMAQPOY3UZ43DVDQB4JLRA5CNFSM4IFPXHDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BGW4Q#issuecomment-516057970, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOUTR2X5G2QDFTWHHEXJLQB4JLRANCNFSM4IFPXHDA .

-- Zoltán Nagy https://abesto.net

cebartling commented 5 years ago

@abesto curl -vvv https://zipkin.io output...

* Rebuilt URL to: https://zipkin.io/
*   Trying 104.31.80.89...
* TCP_NODELAY set
* Connected to zipkin.io (104.31.80.89) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=sni231464.cloudflaressl.com
*  start date: Jul 29 00:00:00 2019 GMT
*  expire date: Aug  5 16:02:15 2019 GMT
*  subjectAltName: host "zipkin.io" matched cert's "zipkin.io"
*  issuer: C=US; ST=MN; L=Shakopee; O=Foobar.com; OU=IS&T; CN=1180 Edge - Foobar; emailAddress=NOC@Foobar.Com
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: zipkin.io
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 29 Jul 2019 16:48:46 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d6a37f274e01ff973c7541f3da09f4e581564418926; expires=Tue, 28-Jul-20 16:48:46 GMT; path=/; domain=.zipkin.io; HttpOnly; Secure
< Last-Modified: Thu, 18 Jul 2019 03:49:58 GMT
< Access-Control-Allow-Origin: *
< Expires: Mon, 29 Jul 2019 16:11:17 GMT
< Cache-Control: max-age=600
< X-Proxy-Cache: MISS
< X-GitHub-Request-Id: 65B4:5FFB:2D90B0:38C6DA:5D3F1849
< Via: 1.1 varnish
< Age: 0
< X-Served-By: cache-msp20829-MSP
< X-Cache: HIT
< X-Cache-Hits: 1
< X-Timer: S1564418926.478687,VS0,VE137
< Vary: Accept-Encoding
< X-Fastly-Request-ID: 50bdfe8e8b0060dd9aae5999681e286a4eafb465
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 4fe095122a8941e1-MSP
<
<!DOCTYPE html>
<html lang="en-us">

  <head>
  <link href="http://gmpg.org/xfn/11" rel="profile">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta http-equiv="content-type" content="text/html; charset=utf-8">

  <!-- Enable responsiveness on mobile devices-->
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1">

  <title>

      OpenZipkin &middot; A distributed tracing system

  </title>

  <!-- CSS -->
  <link rel="stylesheet" href="http://zipkin.io/public/css/poole.css">
  <link rel="stylesheet" href="http://zipkin.io/public/css/syntax.css">
  <link rel="stylesheet" href="http://zipkin.io/public/css/hyde.css">
  <link rel="stylesheet" href="http://zipkin.io/public/css/zipkin.css">
  <link rel="stylesheet" href="http://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">

  <!-- Icons -->
  <link rel="shortcut icon" href="http://zipkin.io/public/favicon.ico">
</head>

  <body class="theme-base-0d">

    <div class="sidebar">
  <div class="container sidebar-sticky">
    <div class="sidebar-about">
      <a href="http://zipkin.io">
        <img alt="Zipkin logo" src="http://zipkin.io/public/img/zipkin-logo-200x119.jpg"
             class="sidebar-logo">
      </a>

      <a href="https://github.com/openzipkin/zipkin" target="_blank" title="openzipkin/zipkin">
        <img class="sidebar-social-icon" alt="openzipkin/zipkin" src="http://zipkin.io/public/img/GitHub-Mark-Light-32px.png">
      </a>

      <a href="https://twitter.com/zipkinproject" target="_blank" title="@zipkinproject">
        <img class="sidebar-social-icon" alt="@zipkinproject" src="http://zipkin.io/public/img/TwitterLogo_white.png">
      </a>

      <a href="https://gitter.im/openzipkin/zipkin/" target="_blank" title="openzipkin/zipkin">
        <img class="sidebar-social-icon" alt="openzipkin/zipkin" src="http://zipkin.io/public/img/gitter.png">
      </a>

    </div>

    <nav class="sidebar-nav">

            <a class="sidebar-nav-item active" href="http://zipkin.io/">Home</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/quickstart.html">Quickstart</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/architecture.html">Architecture</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/tracers_instrumentation.html">Tracers and Instrumentation</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/extensions_choices.html">Server extensions and choices</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/community.html">Zipkin Community</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/data_model.html">Data Model</a>

            <a class="sidebar-nav-item" href="http://zipkin.io/pages/instrumenting.html">Instrumenting a library</a>

    </nav>
  </div>
</div>

    <div class="content container">
      <div class="page">
  <h1 class="page-title">

        Zipkin

  </h1>
  <p>Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data.</p>

<p>If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent in a service, and whether or not operations failed.</p>

<p><img src="http://zipkin.io/public/img/web-screenshot.png" alt="Trace view screenshot" /></p>

<p>The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application. This can be helpful for identifying aggregate behavior including error paths or calls to deprecated services.</p>

<p><img src="http://zipkin.io/public/img/dependency-graph.png" alt="Dependency graph screenshot" /></p>

<p>Application’s need to be “instrumented” to report trace data to Zipkin. This usually means configuration of a <a href="http://zipkin.io/pages/tracers_instrumentation">tracer or instrumentation library</a>. The most popular ways to report data to Zipkin are via http or Kafka, though many other options exist, such as Apache ActiveMQ, gRPC and RabbitMQ. The data served to the UI is stored in-memory, or persistently with a supported backend such as Apache Cassandra or Elasticsearch.</p>

<h2 id="where-to-go-next">Where to go next?</h2>

<ul>
  <li>To try out Zipkin, check out our <a href="http://zipkin.io/pages/quickstart">Quickstart guide</a></li>
  <li>See if your platform has a <a href="http://zipkin.io/pages/tracers_instrumentation">tracer or instrumentation library</a></li>
  <li>See if a <a href="http://zipkin.io/pages/extensions_choices">server extension or alternative</a> is relevant to your site.</li>
  <li>Join the <a href="https://gitter.im/openzipkin/zipkin">Zipkin Gitter chat channel</a></li>
  <li>The source code is on GitHub as <a href="https://github.com/openzipkin/zipkin/">openzipkin/zipkin</a></li>
  <li>Issues are also tracked on <a href="https://github.com/openzipkin/zipkin/issues">GitHub</a></li>
</ul>

</div>

    </div>

  </body>
</html>
* Connection #0 to host zipkin.io left intact
abesto commented 5 years ago

Huh. curl is happy with the certificates, but both Chrome and Safari aren't (I'm making the assumption that Safari is also broken due to the SSL stuff). I've tried to reproduce by going through a couple of proxies in the US, but failed.

Unfortunately @cebartling your machines are still the only ones we have with the issue, so I need to ask you for more information. Next step would be I think to get the cert details from Chrome - both on what cert it's using, and what its problem is. Ideal would be screenshots of what Chrome tells you, and an export of the cert it says it's received.

Worst case, if this still doesn't explain what's going on, this will be enough for me to open a support ticket with CloudFlare.

Couple of shots in the dark: is the date/time on the machines where you're experiencing this accurate? Do you have any (weird) custom proxy setup? Do you have any kind of non-standard certificate management on your machines?

cebartling commented 5 years ago

@abesto I'll get you the certificate information in the morning. Thanks for continuing to investigate this.

anuraaga commented 5 years ago

It looks like curl and browsers are having the same behavior where they trust the index.html certificate, and as we can see in the curl dump the URLs point to http://zipkin.io, which will cause mixed-content errors in a browser.

The certificate listed looks wrong though, a cloudflare cert should have an issuer of COMODO but this appears to have been issued by something that isn't a certificate authority. The chance of a company-managed man-in-the-middle proxy rewriting the content seems likely - you might want to edit the comment to remove the TLS information in case the company's name shouldn't be in this public history. And you'll probably want to ask your company's IT team on what is causing their proxy to rewrite the URLs as http://.

abesto commented 5 years ago

@anuraaga Nice catches, thanks for looking closely! I tend to agree with your analysis.

cebartling commented 5 years ago

@anuraaga Edited comment to remove TLS information.

cebartling commented 5 years ago

@abesto Here is the certificate information from a Chromium browser running on my Ubuntu system here at home that exhibits the same issue. This is an attempt to view the page from my Comcast Business Internet network, so no organizational IT proxy to deal with. Same issues with http:// URLs.

Screenshot from 2019-07-30 07-42-28

abesto commented 5 years ago

Everything about this is weird.

The cert in your screenshot matches the cert I'm seeing on my end (where the site loads fine). Note the difference between the certificate listed in the screenshot and the curl dump, specifically this line:

*  issuer: C=US; ST=MN; L=Shakopee; O=Foobar.com; OU=IS&T; CN=1180 Edge - Foobar; emailAddress=NOC@Foobar.Com

I wonder of curl and your home Chromium even affected by the same issue. We could verify this by getting another curl dump, this time from your home box. I checked just in case, the issuer details don't match the issuer of the cert used by https://foobar.com (which is a suspended site ATM anyway) :D

That said, this seems to be a red herring. On further research (ie. desperate Google usage) this seems to be an instance of https://github.com/github/pages-gem/issues/238. Indeed we don't have "Enforce HTTPS" enabled (and GitHub reports we're not correctly configured for HTTPS). I'm at a loss about why this seems to affect @cebartling and not everyone.

I intend to debug why GH thinks HTTPS is not correctly configured for zipkin.io, fix that, and enable "Enforce HTTPS". @adriancole this would be a good time to shout if you're worried about breaking HTTP-only clients.

abesto commented 5 years ago

Oh my. At least one reason for GH thinking HTTPS is incorrect is that the CNAME file is broken. It needs to not have a trailing new-line (as fixed in https://github.com/openzipkin/openzipkin.github.io/commit/f84553580769872b628526d21e423e29a7a7102a#diff-adc4bfdb0829dae99e3699393e3fbaa4). This was broken when back-porting changes from the ASF version for some reason, in https://github.com/openzipkin/openzipkin.github.io/commit/3287ea402c43013a8da18eebf309b9c25e6dac4e#diff-adc4bfdb0829dae99e3699393e3fbaa4.

I've just fixed this in https://github.com/openzipkin/openzipkin.github.io/commit/1669bf0fc99c0a1e37c530a9da5fe372a4f8e2ab; now we wait a bit for GH Pages to pick up the change.

codefromthecrypt commented 5 years ago

@adriancole https://github.com/adriancole this would be a good time to shout if you're worried about breaking HTTP-only clients.

on pointing to https (not your question): we did a lot of maintenance to avoid links in poms and README to http://zipkin.io however, I've not done a github crawl and I suspect there will be many old links.

currently unconcerned about http only clients, should we be?

abesto commented 5 years ago

currently unconcerned about http only clients, should we be?

I don't think so, but wanted to check if you have anything specific in mind anyway. In fact, I vaguely remember a decision to enable enforcing HTTPS on the GitHub side some time ago. On further thought, I'm pretty sure it must have been enabled, otherwise everyone would be experiencing the same issue as reported in this thread (see the pages-gem issue above).

By now I would've expected GH Pages to pick up the change, and it didn't (or else some other problem exists as well). I'll probably "nudge" GH Pages by changing the configured custom domain to whatever else, then changing it back to zipkin.io at some point.

On a related note: when GH added HTTPS support for Pages, they also added a CDN (https://github.blog/2018-05-01-github-pages-custom-domains-https/), so I'd propose dropping CloudFlare-the-CDN to simplify our setup. We can still keep using CloudFlare-the-DNS-server. I'd actually recommend doing so, because (1) the management interface is preferable to our domain registrar and (2) CloudFlare supports CNAME flattening.

codefromthecrypt commented 5 years ago

thanks for tracking developments. good to see we can limit the infra to what's differentiated!

On Sat, Aug 3, 2019, 2:44 PM Zoltán Nagy notifications@github.com wrote:

currently unconcerned about http only clients, should we be?

I don't think so, but wanted to check if you have anything specific in mind anyway. In fact, I vaguely remember a decision to enable enforcing HTTPS on the GitHub side some time ago. On further thought, I'm pretty sure it must have been enabled, otherwise everyone would be experiencing the same issue as reported in this thread (see the pages-gem issue above).

By now I would've expected GH Pages to pick up the change, and it didn't (or else some other problem exists as well). I'll probably "nudge" GH Pages by changing the configured custom domain to whatever else, then changing it back to zipkin.io at some point.

On a related note: when GH added HTTPS support for Pages, they also added a CDN (https://github.blog/2018-05-01-github-pages-custom-domains-https/), so I'd propose dropping CloudFlare-the-CDN to simplify our setup. We can still keep using CloudFlare-the-DNS-server. I'd actually recommend doing so, because (1) the management interface is preferable to our domain registrar and (2) CloudFlare supports CNAME flattening.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openzipkin/openzipkin.github.io/issues/135?email_source=notifications&email_token=AAAPVV7SST7YCUJ7VHKK6OLQCUSNFA5CNFSM4IFPXHDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PIOSA#issuecomment-517900104, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPVV7ZRIX4VRN2YZUKLW3QCUSNFANCNFSM4IFPXHDA .

abesto commented 5 years ago

Just changing the CNAME file didn't help. I'm out of non-disruptive options; I'm about to disable the CDN part of CloudFlare, mess around with the GH Pages config, and just keep pushing buttons until stuff starts to work.

Expect 404s and possibly failing HTTPS connections / certificate errors to https://zipkin.io in the next few hours. (Also, let me know if we should establish some protocol for notifying users about such disruptions in the future)

abesto commented 5 years ago

Alright, that was surprisingly quick and easy. CloudFlare CDN is disabled, GH Pages HTTPS is up and enforcing HTTPS.

$ dig zipkin.io

; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> zipkin.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46253
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;zipkin.io.                     IN      A

;; ANSWER SECTION:
zipkin.io.              57      IN      A       185.199.111.153
zipkin.io.              57      IN      A       185.199.108.153
zipkin.io.              57      IN      A       185.199.109.153
zipkin.io.              57      IN      A       185.199.110.153

;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Aug 04 13:16:16 BST 2019
;; MSG SIZE  rcvd: 102

I'm currently seeing two mixed-content warnings in Chrome for loading Google Web Fonts, whose URLs are indeed hard-coded in the source as http://. I'm already doing stuff to the site live, so fixed this directly on master in https://github.com/openzipkin/openzipkin.github.io/commit/722860f9c7f086d7cebf8bf55f641841c0b6dcfe.

@cebartling If you would be so kind as to check how things look now? I expect you to be able to load the site now.

cebartling commented 5 years ago

@abesto Indeed the site does properly load for me now! Thank you so much for your efforts on this issue. Kudos!