Skip Navigation

Stats Badge on Users Page not updating

Travel Forums System Talk Stats Badge on Users Page not updating

  • 1
  • 2

Last Post

11. Posted by Sander (Moderator 4817 posts) 21w


I still see 86/102 for both images! If I visit via secure, I see 87/103.

Peter, it's cloudflare. It looks like there's no expires headers, etags or anything else sent along with this image (checked this on secure; because they're directly generated by the server, I suspect?), so cloudflare apparently then caches them with an expiry of a month (checked on www), and those servers never check the source again, but because of their geographical distribution, I am hitting a different one than Kate, which is why mine fetched a fresh copy yesterday (which is now stale).
The only question is, why did this update for you? Maybe you have a setting somewhere to bypass cloudflare as admin, or did your latest check on secure rather than www?

(Kate, I suspect the above is then clear for you, but for any non-IT people reading along: The problem is indeed between Kate and travellerspoint, but on a layer which travellerspoint put in, which is intended to improve the speed of the site...)

[ Edit: Edited on 21-May-2016, at 00:16 by Sander ]

12. Posted by katebum (Budding Member 100 posts) 21w

I now deleted my test trip... so the numbers we're talking about is 86/102

I checked both types of connections... http and https .... for me there is no difference... I always see 84/99

I always try from Germany ... perhaps this is from interest to you....

Please let me know when I can help....

13. Posted by katebum (Budding Member 100 posts) 21w

Here are the HTTP headers of a non secure connection (dleted the cookie) ..... Sander is right... the expired header is set to one month...

This was the first time yesterday I tried this image with the firefox developer edition so I expected that 86/102 to see... this was not the case.... so I think the problem is not that the cloudflare server CF-RAY: 2a66ae45d96a1adb-DUS is sending this expires header by his own... I think he will get this info/header from a stage behind....


GET /badges/stats561470-1.png HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 200 OK
Date: Sat, 21 May 2016 08:32:57 GMT
Content-Type: image/png;charset=UTF-8
Content-Length: 5900
Connection: keep-alive
Display: staticcontent_sol
Expires: Mon, 20 Jun 2016 08:32:57 GMT
Response: 200
Vary: Accept-Encoding
X-Middleton-Display: staticcontent_sol
X-Middleton-Response: 200
Content-Encoding: gzip
Cache-Control: public, max-age=2592000
CF-Cache-Status: HIT
Server: cloudflare-nginx
CF-RAY: 2a66ae45d96a1adb-DUS

14. Posted by Peter (Admin 5790 posts) 21w

Those headers there for are the cloudflare server -- see "Server: cloudflare-nginx"

This one bypasses Cloudflare: (should show IIS as the server)

I've just set up a rule in Cloudflare that should bypass the cache for these images. Not sure how long till that takes effect and I guess any images that are already have the cache settings may not benefit from it. I'm off for the night, but I'll have a look tomorrow and see whether the setting has had an effect.

15. Posted by katebum (Budding Member 100 posts) 21w

well done! works!

16. Posted by Peter (Admin 5790 posts) 21w

It still has these two headers:

Cache-Control:"public, max-age=2592000"

Expires:"Tue, 21 Jun 2016 01:05:36 UTC"

So browsers, etc. could still cache the image. However, what's now not showing is this one:

CF-Cache-Status: HIT

So that seems to be where the really persistent caching was happening. Hopefully this is a good enough middle ground. A little caching is not a bad thing after all :)

  • 1
  • 2