Pokeapi: Xatu's species redirect from pokemon/xatu return an invalid URL

[ZKillou]

Description :

When I get the Xatu's page, I get the Xatu's species page too with the URL given in the "species" object but when I get the species page, the content of the page is "Not found". I have checked why and I have seen when we write the URL with a / at the end of the URL ( https://pokeapi.co/api/v2/pokemon-species/178/ ) the page is invalid but without this / (https://pokeapi.co/api/v2/pokemon-species/178 ) the page is valid

Steps to Reproduce:

1. Go to the page : https://pokeapi.co/api/v2/pokemon/178
2. Use the species URL
3. The URL is invalid

[Kronopt]

@Naramsim, I think this is some sort of caching issue again.
I have no problem accessing both urls (with and without the / at the end)

[Naramsim]

Ok, I had the very same issue myself. I think some of the caches of Cloudflare had broken data. To solve the issue I had to:

1. purge Cloudflare
2. use an incognito window (even after a browser restart, the resource gives a _Not Found_)

The last step is due to our policy that instructs the browser to cache files for 1 day. cache-control: public, max-age=86400, s-maxage=86400

I have to look a bit deeper about how those headers work. I remember there is one that forces the browser to revalidate the request. So maybe it's better to change something in our headers.

[Naramsim]

I'd go with something like:

Cache-Control: public, max-age=3600, s-maxage=3600, must-revalidate
# or
Cache-Control: public, max-age=60, s-maxage=60, must-revalidate

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

public means browsers and Cloudflare will cache the request. I'd shorten max-age to 1h or 1m. And also add must-revalidate so that if the 1h/1m has passed the resource will be checked against pokeapi.co

I'm also unsure how Cloudflare works when s-maxage is set. I don't think it takes it into account since we've enabled _Cache Everything_

---

I'd like to know also the opinion of the other @PokeAPI/core-team members.

[cmmartti]

I don't know a whole lot about caching, etc., but I think the reasoning behind instructing the browser to cache for one day is that the data is static and so there's no point requesting new data if you already have it. But since it's all cached behind Cloudflare now and any additional requests don't increase server costs, it probably makes sense to decrease that down to one hour or even one minute if it fixes any errors that might happen.

[Naramsim]

As a side note I want to say that the issue still persists on my machine. When I browsed the incognito webpage, I was served an old copy of data. As soon as I reloaded I got the 404. The same happened with my phone.

I tested on Pingdom (https://tools.pingdom.com/) and:

from Frankfurt I receive 404
from Tokyo 200
from SF 200
from London 200
from Sydney 200

So now I'm thinking more of a problem with Cloudflare itself. There was also another issue with some guys from Poland today having problems retrieving the pokemon 56.

Let's see if the issue persists also tomorrow.

[ZKillou]

Hi, the issue is fixed for me, I can access to Xatu's species page with a /, thanks for your help !

[Naramsim]

Yeah, I had to purge the Cloudflare cache manually.

Thanks anyway @ZKillou for reporting the issue.

[ZKillou]

Hi ! This problem happend again with the Hentei's species page, Cloudflare has some problem again ?

[Kronopt]

Please verify that you're calling the "entei" endpoint and not "hentei"

[Naramsim]

Entei works fine on my end, both pokemon and pokemon-species with or without trailing slash.

Also Pingdom gives 200 from Frankfurt.

[ZKillou]

Sorry, the problem happend with the number of the pokemon : https://pokeapi.co/api/v2/pokemon-species/244/

[Naramsim]

Yeah, happening also here

[Naramsim]

Ok, so after one day Cloudflare purged its cache and now the resource is correctly served with a 200.