search

McLive / api.minetools.eu

Issuetracker for the Minetools API.
2 stars 0 forks source link

Response caching #36

Closed DylanKeir closed 3 years ago

DylanKeir commented 3 years ago

Hi there, I work at https://tcpshield.com and we just had to manually unblock your API from our network as one of our users was having trouble with it not working. It was originally blocked due to your users spamming requests which get forwarded to us and our systems automatically blocked you.

We're recommending you either implement global caching or if you prefer not to cache requests, at least cache requests to any servers pointing to *.tcpshield.com via CNAME records or via SRV, you can view our entire IP range at https://tcpshield.com/v4 for this.

Your API may be automatically blocked in the future since you're proxying L7 floods to us.

Thanks, Dylan.

McLive commented 3 years ago

Hi, there already is a global cache implemented for UUID and PING endpoints, which I assume you are talking about.

Can you send additional information why it got blocked as I currently can't see any reason?

DylanKeir commented 3 years ago

Sorry, should've clarified. I mean server ping caching, this endpoint: https://api.minetools.eu/ping/

As you know, users can utilize this endpoint to directly ping a server but there seems to be no caching on it as every request is being forwarded through us.

McLive commented 3 years ago

There actually is a cache for that endpoint. Someone changing the port will of course send a new request.

cache time for failed requests: 5s cache time for succeeded requests: 15s

DylanKeir commented 3 years ago

Hm, we tested this earlier and we were being pinged for every request we made through your API, however re-testing again now and we're hitting the cache. Strange.

McLive commented 3 years ago

That is indeed weird 🤔

DylanKeir commented 3 years ago

Suppose I'll close this since it doesn't appear to be an issue anymore. Appreciate the quick responses.