Obsolete cached InRelease file is returned by Cloudfront when using URL-encoded colons (%3a instead of :) in path

[njoyneer]

What happened:

In one of our locations (San-Francisco datacenter) we observed an issue when some package couldn't be installed.

We tracked down the problem to the following: we're using apt-cacher that URL-encodes the path
InRelease file was updated yesterday (last-modified: Wed, 23 Apr 2025 03:08:31 GMT) and the old version (last-modified: Wed, 12 Mar 2025 02:03:58 GMT) stayed in the CF cache reachable from our San-Francisco location.
When requesting the file with a command
curl -v -s http://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.30/deb/InRelease
correct version was returned
When requesting the file with a command
curl -v -s http://prod-cdn.packages.k8s.io/repositories/isv%3a/kubernetes%3a/core%3a/stable%3a/v1.30/deb/InRelease
the old file was returned
Today the problem disappeared and a new file is returned in both cases

What you expected to happen:

Latest file version is returned by CDN when using URL-encoded path

How to reproduce it (as minimally and precisely as possible):

Update InRelease (also should work with any other file)
curl it with a command
curl -v -s http://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.30/deb/InRelease
curl it with a command
curl -v -s http://prod-cdn.packages.k8s.io/repositories/isv%3a/kubernetes%3a/core%3a/stable%3a/v1.30/deb/InRelease
compare last-modified headers

Anything else we need to know?:

Environment:

Debian OS