I have a file that I’ve set for max-age: 1 day, but I wanted to bust it early for testing something out.
https://test.stellarguard.me/.well-known/stellar.toml, with an origin here: https://stellarguard-test.appspot.com/.well-known/stellar.toml
I manually purged it in the as a single item in the Cloudflare UI, but it still is showing the old content while the origin shows the updated value. Any ideas?
I see that the content of the two files are identical now.
If you still see the old version, then it might be that your browser has the file in cache. Try clearing your browsers cache. (Windows: CTRL + F5 / Mac OS X: CMD + Shift + R)
I’ve tested it with multiple browsers (one of which has never requested the file), and it still has the old value. Same as when I disable cache, force reload, or use curl.
It’s showing
MULTISIG_SERVER=“https://stellarguard.me/api/transactions”
when it should be showing:
MULTISIG_SERVER=“https://test.stellarguard.me/api/transactions”
Which URL are you testing?
Both URLs in your opening post are showing the same content for me:
➜ ~ curl https://test.stellarguard.me/.well-known/stellar.toml
MULTISIG_SERVER="https://test.stellarguard.me/api/transactions"%
➜ ~ curl https://stellarguard-test.appspot.com/.well-known/stellar.toml
MULTISIG_SERVER="https://test.stellarguard.me/api/transactions"%curl https://test.stellarguard.me/.well-known/stellar.toml -v
* Hostname was NOT found in DNS cache
* Trying 104.27.171.129...
* Connected to test.stellarguard.me (104.27.171.129) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* Server certificate: sni217501.Cloudflaressl.com
* Server certificate: COMODO ECC Domain Validation Secure Server CA 2
* Server certificate: COMODO ECC Certification Authority
* Server certificate: AddTrust External CA Root
> GET /.well-known/stellar.toml HTTP/1.1
> User-Agent: curl/7.37.1
> Host: test.stellarguard.me
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 15 Oct 2018 06:36:09 GMT
< Content-Type: text/plain; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d9c9a931b87b9d2f5ed7ba20f3f2460601539585369; expires=Tue, 15-Oct-19 06:36:09 GMT; path=/; domain=.stellarguard.me; HttpOnly; Secure
< Vary: Accept-Encoding
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Last-Modified: Thu, 04 Oct 2018 03:09:17 GMT
< ETag: W/"3a-1663d0d0b48"
< Via: 1.1 google
< Cache-Control: public, max-age=86400
< Age: 7700
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< X-Content-Type-Options: nosniff
< Expect-CT: max-age=604800, report-uri="https://report-uri.Cloudflare.com/cdn-cgi/beacon/expect-ct"
* Server Cloudflare is not blacklisted
< Server: Cloudflare
< CF-RAY: 46a045100cbf2525-ORD
<
* Connection #0 to host test.stellarguard.me left intact
MULTISIG_SERVER="https://stellarguard.me/api/transactions"That is indeed quite confusing.
➜ ~ curl https://test.stellarguard.me/.well-known/stellar.toml -v
* Trying 104.27.170.129...
* TCP_NODELAY set
* Connected to test.stellarguard.me (104.27.170.129) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=sni217501.Cloudflaressl.com
* start date: Sep 23 00:00:00 2018 GMT
* expire date: Apr 1 23:59:59 2019 GMT
* subjectAltName: host "test.stellarguard.me" matched cert's "*.stellarguard.me"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f9fa3807000)
> GET /.well-known/stellar.toml HTTP/2
> Host: test.stellarguard.me
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Mon, 15 Oct 2018 06:56:07 GMT
< content-type: text/plain; charset=utf-8
< set-cookie: __cfduid=dbcc28a8c2b1014d7b7bef9e30f4d05d01539586567; expires=Tue, 15-Oct-19 06:56:07 GMT; path=/; domain=.stellarguard.me; HttpOnly; Secure
< vary: Accept-Encoding
< x-powered-by: Express
< access-control-allow-origin: *
< content-disposition: inline
< last-modified: Thu, 04 Oct 2018 03:09:20 GMT
< etag: W/"3f-1663d0d1700"
< via: 1.1 google
< cache-control: public, max-age=86400
< age: 1646
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-content-type-options: nosniff
< expect-ct: max-age=604800, report-uri="https://report-uri.Cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: Cloudflare
< cf-ray: 46a0624f58a83319-HKG
<
* Connection #0 to host test.stellarguard.me left intact
MULTISIG_SERVER="https://test.stellarguard.me/api/transactions"%
Obviously I am hitting a different PoP compared to you, but I actually think the issue here is that your origin responds to Cloudflare with the old value. The Google App Engine machine that is close to the Cloudflare PoP you are hitting might still have the page in cache.
I am not familiar with Googles platform, perhaps there is an option to invalidate cache at their side as well?
Cloudflare doesn’t add any CF-Cache-Status header to the response, so Cloudflare isn’t caching the request.
Looking at the headers you posted I don’t see a CF-Cache-Status value, so this does not appear to be an object being served from Cloudflare’s cache. I think @martin2 is on the right track, something may be cached, but it is at the origin and should be purged there.
-OG
I know there’s people here helping out far better than I by looking at headers etc. but I would like to just say that from a purely anecdotal stand-point I’ve also had this recently too with Google App Engine content served via the Sydney DC.
I tried and tried to remove cached objects via ‘Purge all’ and individual URLs in the last week but they kept being served (GAE?). Caused me a massive headache as I load all my resources with SRI hashes so the old files stopped my sites working. I ended up having to change all the filenames of the updated resources to get things fixed. As it happens, my new naming scheme was better than the old so I was happy being forced into doing so but still, from what I saw I also think that objects may be hanging around in the cache when they shouldn’t be (last week or so). No idea where the issue is and didn’t have time to troubleshoot.
At least this post proves I wasn’t going mad!!
This topic was automatically closed after 31 days. New replies are no longer allowed.
