The website's documentation is returning a 404

[evanlucas]

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]

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]

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

[joaocgreis]

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

Duplicate: nodejs/nodejs.org#1391

[knksmith57]

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:

• http://bit.ly/node-6-api-docs-mirror
• http://bit.ly/node-8-api-docs-mirror

thanks for following up, @joaocgreis

[erinishimoticha]

I'm still receiving 404s at DFW.

[gibfahn]

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]

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]

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]

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]

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]

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]

/cc @cloudflare
https://twitter.com/refack/status/917396135995637760
because internet

[rvagg]

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]

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]

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]

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

[rvagg]

@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]

@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]

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]

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

[refack]

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

[evanlucas]

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

[rvagg]

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]

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 :]