Caching on non-standard ports

Continuing the discussion from CF simply refuses to cache my content:

Unless I completely missed something, that was new to me. Is that intended behaviour or an actual issue with the proxies?

IIRC it worked. I’ll check that once i am at home. A pitty that there is no developer tools in Chrome mobile :sweat_smile:

To be honest, I dont know if it ever worked, I only played once with custom ports and that was when I checked how Flexible applied.

Today I ran a modified version of that code and it did seem as if I was able to confirm that caching appears to be non-functional on custom ports. I have a hard time believing it, but my tests - again, unless I messed something up - do seem to confirm it.

I stress that all the time as I consider it more probable than Cloudflare not caching on these ports, but then who knows :slight_smile:

99,99% sure: there were HITS in the past
Plesk feels much slower than before and cf-cache-status is DYNAMIC for each request.

There is no cache-control header though… Could be that?

Good catch. Another one on port 443

There is no cache control in either case. Also, its presence with certain values usually prevents caching, not its absence.

In my test, I ran the identical request/response via port 443 and 8443. The former cached, the latter didnt. Either I messed something up (benefit of the doubt) or there really is an issue. To be honest, I’d rather tend to the second explanation at this point.

2 Likes

Yeah, at this point I would tend to the same issue…

1 Like

Apparently, that is by design. Only 80 and 443 are considered by the cache.

1 Like

Sounds vaguely familiar… Not sure why we made the decision exactly but we could probably revisit it if you have a few million to spend. :slight_smile: Otherwise the 12 people in the world who want this will have to ponder their life choices.

1 Like

I am not even using Cache Everything :wink:

I am not sure, though, why Cloudflare would pull a Sanders*) here. Enabling caching for the other ports cant go into the billions, or can it?


*) Really just an innocent reference, no Sanders bashing. From my perspective, the only sensible candidate in this circus.

1 Like

If the port isn’t part of the cache key (ie. it assumes 443 and 80 are the same website and can share a cache) then the cache working on the other ports would probably conflict and pulling :8443/a.png would be checking :443/a.png. The solution could be to make the port part of the key and default 80 and 443 to something like default but that logic hasn’t needed to be there yet.

1 Like

The port is a standard part of the URL, so I’d have assumed it is part of the key.

Just checked, if Cloudflare follows protocol the cache key should include the port

${header:origin}::${scheme}://${host_header}${uri}

If we followed protocols we wouldn’t allow you to create a CNAME for the root. :slight_smile:

I don’t know our exact implementation but I’d imagine we simply skip the cache layer entirely if it didn’t come in on 80/443. Seems like the simplest method to implement and I am but a simple SE.

2 Likes

No objection from my side.

That’s how I understood it.

Though, diverting from standards to provide additional features should not be a reason to divert from standards where you take features away.

I’d say the biggest issue here is that it is seemingly nowhere documented. I had no idea caching wouldnt work on non-standard ports and apparently nobody else from the regulars either. Hence my surprise and my original statement

You don’t allow CNAMEs at the root, instead you confuse a CNAME with dynamically updating the A/AAAA records.

While this largely does work, it is not particularly well named as this CNAME does not work entirely the same as an actual CNAME.

DNSMadeEasy differentiates the record types with a non-standard ANAME, allowing users to understand the difference.

From Identifying network ports compatible with Cloudflare’s proxy:

Ports 80 and 443 are the only ports compatible with:

2 Likes