Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The website's documentation is returning a 404 #905

Closed
evanlucas opened this issue Oct 6, 2017 · 24 comments
Closed

The website's documentation is returning a 404 #905

evanlucas opened this issue Oct 6, 2017 · 24 comments

Comments

@evanlucas
Copy link

Moving from nodejs/nodejs.org#1390.

https://nodejs.org/dist/latest-v8.x/docs/api and https://nodejs.org/dist/latest-v6.x/docs/api

@joaocgreis
Copy link
Member

I cannot reproduce now, pages load fine here. If this is still happening, do you have a way to check if it happens on multiple computers / ISPs?

@refack
Copy link
Contributor

refack commented Oct 6, 2017

Work for me (Comcast East Coast 65.96.x.x)

@joaocgreis
Copy link
Member

I've cleared the Cloudflare cache, don't know if that will help.

Duplicate: nodejs/nodejs.org#1391

@knksmith57
Copy link

tunneling through DO's SFO1 datacenter results in a 200. Here in Austin, TX my edge is still receiving the 404.

looks like we're just playing a waiting game now.

for others following along at home, static mirrors:

thanks for following up, @joaocgreis

@erinishimoticha
Copy link

I'm still receiving 404s at DFW.

@gibfahn
Copy link
Member

gibfahn commented Oct 7, 2017

This seems like something we should contact Cloudflare about. @mhdawson @joaocgreis @jbergstroem @rvagg I'm not sure how we do this, is there someone we could cc in this issue?

@refack
Copy link
Contributor

refack commented Oct 7, 2017

I commented on nodejs/nodejs.org#1391 (comment), trying to figure out what CF is caching. If everything was OK or if there was a time-window with 404s?
This sounds like a counterintuitive behaviour of CF, if we have "Always-on" it should actually behave in the opposite manner.

@phillipj
Copy link
Member

phillipj commented Oct 7, 2017

Just chiming in to confirm the docs works as expected in the Norway/Oslo area. Sadly I don't have any knowledge about the Cloudflare setup or how to contact them :/

@joaocgreis
Copy link
Member

We have some CI machines at DFW and I can confirm this is an issue only there.

As noted in #676 (comment) , Cloudflare is configured to fall back to http://unencrypted.nodejs.org/download/ when the primary server is not accessible. I can access the main server by IP from the machines at DFW, I don't know why Cloudflare is not using it.

There were no docs folders in that server, there was a systemd timer that was not executing because it did not have the full path in ExecStart and a crontab entry that was doing the work but excluded docs. I left only the timer and fixed it (ref #590).

@refack
Copy link
Contributor

refack commented Oct 8, 2017

Can we add those URLs (http://unencrypted.nodejs.org/download/release/latest-v6.x/docs/api/ and http://unencrypted.nodejs.org/download/release/latest-v8.x/docs/api/) to download-test.sh?

@joaocgreis
Copy link
Member

This is still an issue for https://coverage.nodejs.org/ and https://nodejs.org/metrics/ at least. I don't have any experience with Cloudflare, but we should probably figure out why it's not using the main server. cc @jbergstroem @rvagg

@refack
Copy link
Contributor

refack commented Oct 9, 2017

@rvagg
Copy link
Member

rvagg commented Oct 10, 2017

I've made some tweaks to the SSL config on the backup server, maybe that'll help.

Taking this to private email with CF along with @mhdawson for now, will report back if we hear anything helpful.

@rvagg
Copy link
Member

rvagg commented Oct 11, 2017

Some progress, this is interesting so I thought I'd share. There is an API for querying the status of load balancer pools on CF. Doing so, with our account (curl https://api.cloudflare.com/client/v4/user/load_balancers/pools/POOL_ID/health -H "X-Auth-Email: AUTH_EMAIL" -H "X-Auth-Key: AUTH_KEY") shows that they are all healthy except Dallas, TX:

      "Dallas, TX": {
        "healthy": false,
        "origins": [
          {
            "PRIMARY_SERVER_IP": {
              "healthy": false,
              "rtt": null,
              "failure_reason": "TCP connection failed",
              "response_code": null
            }
          },
          {
            "SECONDARY_SERVER_IP": {
              "healthy": false,
              "rtt": null,
              "failure_reason": "TCP connection failed",
              "response_code": null
            }
          }
        ]
      },

(IP addresses edited out)

Same error on two servers hosted by completely different providers, ongoing for a few days now, so I'm assuming it's on their end. Waiting to hear more on this from them.

@rvagg
Copy link
Member

rvagg commented Oct 11, 2017

It looks like Dallas, TX has been taken out of the edge list, maybe to fix up a problem, hopefully that means that traffic is being sent somewhere nearby to a healthy edge and that this is "fixed". Would love to hear from people who were having trouble with it previously.

@evanlucas
Copy link
Author

https://coverage.nodejs.org still isn’t working for me. It shows the websites homepage and redirects to https://coverage.nodejs.org/en

@rvagg
Copy link
Member

rvagg commented Oct 11, 2017

@evanlucas clear your cache perhaps? I don't think that one's related to CF, there's some funky nginx redirect stuff I've been noticing related to http/https and this sounds similar.

@knksmith57
Copy link

@rvagg from Austin, TX I'm now seeing correct content for the first time in 5 days:

❯ curl -iIX GET https://nodejs.org/dist/latest-v6.x/docs/api/
HTTP/1.1 200 OK
Date: Wed, 11 Oct 2017 03:30:29 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d4b8d8ec2041e46aeaecb8d69a018c9691507692629; expires=Thu, 11-Oct-18 03:30:29 GMT; path=/; domain=.nodejs.org; HttpOnly
Last-Modified: Tue, 03 Oct 2017 17:14:42 GMT
CF-Cache-Status: HIT
Expires: Wed, 11 Oct 2017 07:30:29 GMT
Cache-Control: public, max-age=14400
Server: cloudflare-nginx
CF-RAY: 3abebdb45a4957f5-DFW

Speculating here, but the CF-RAY header leads me to believe CF is now serving correct content from Dallas.

@rvagg
Copy link
Member

rvagg commented Oct 11, 2017

Still not seeing Dallas, TX in the edge list from their API but I did remove the backup server and then put it back in in our config in the hopes that would give them all a jolt, I guess there's a chance that's helped. Will wait to hear back from them.

@prototypeme
Copy link

From Dallas, TX, just wanted to confirm the doc links are working fine now. Thanks for fixing.

@refack
Copy link
Contributor

refack commented Oct 12, 2017

Double confirmation so closing (DFW area users please comment if wrong)

@refack refack closed this as completed Oct 12, 2017
@evanlucas
Copy link
Author

the docs work for me, but https://coverage.nodejs.org still redirects to https://coverage.nodejs.org/en.

@rvagg
Copy link
Member

rvagg commented Oct 16, 2017

Hey @evanlucas, this is precisely what's on the server for coverage.nodejs.org: https://github.com/nodejs/build/blob/master/setup/www/resources/config/coverage.nodejs.org, I don't see anything in there that would be causing a redirect. Do you still get it after clearing cache? Can you replicate the behaviour with another browser or curl?

There's a small possibility this is an SNI thing but I don't imagine you're running a browser old enough to be bothered by the fact that we're serving multiple https hosts off the same host. If it continues to happen I could see how switching on CloudFlare serving for that host goes, maybe that'll make an impact.

Status update from CloudFlare on the Dallas issue: last I heard from them they said that the edge server team was looking into it. I believe we're essentially solved on the problem and anything outstanding is on their end so 👍 I suppose.

@evanlucas
Copy link
Author

This is finally working for me now. I had cleared dns cache and all that, but even curl was still responding with a 301. Sorry for all the noise and thanks for following up @rvagg :]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants