html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/1873#issuecomment-368628179,https://api.github.com/repos/pydata/xarray/issues/1873,368628179,MDEyOklzc3VlQ29tbWVudDM2ODYyODE3OQ==,30583,2018-02-26T19:52:47Z,2018-02-26T19:52:47Z,MEMBER,Okay I'll turn on the HTTPS proxy service. Let me know if you notice anything unexpected.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,293272998
https://github.com/pydata/xarray/issues/1873#issuecomment-368575586,https://api.github.com/repos/pydata/xarray/issues/1873,368575586,MDEyOklzc3VlQ29tbWVudDM2ODU3NTU4Ng==,30583,2018-02-26T17:11:41Z,2018-02-26T17:11:41Z,MEMBER,"Hello if you find troubles with pydata.org definitely send mail to web@pydata.org

In this case, which is completely different from the Dask cask, xarray.pydata.org is registered as a cname to read the docs. While pydata.org does serve via Nginx subdomains do not point to that server.

Read the docs is serving a security certificate with itself as the domain authority. The browser correctly recognizes that this is not the correct certificate for a custom domain, (only really good for things like: https://readthedocs.org/projects/xray/)

If there is a desire to serve a https from the xdata.pydata.org, I can set up a certificate on cloudflare which will terminate the https request and forward the http request to readthedocs. As Dask has found there is a bug somewhere that redirects some pages on read the docs from https to http, but we can cross that bridgw when we get there.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,293272998