There’s ongoing issue with Cloudflare IPFS gateway cloudflare-ipfs.com, which affects only some Cloudflare IPFS PoPs (≈regions) and happens quite frequently.
The gateway does not serve the whole file and cuts it off in different places, for the whole file cache lifetime.
Here’s the example of such file:
It is 676614 bytes in size, but the real file is 950 kB.
Once the file is cached being cut-off, it is served in this state all the time in the same region, while the other regions are not affected, which encumbers debugging the issue.
Opening the file using other IPFS gateways, such as ipfs.io, returns full uncut file:
The full file has “return “DIRECT”;” string in the end of it.
Cut-off file served on Russian Cloudflare PoP:
I’ve tried to pre-download the file over multiple gateways before serving it on the website, but that doesn’t help much, it still eventually getting served broken in some regions but not in other.
This file has been broken in Russia since 26 December and is still served cut-off:
Please check what could be wrong with the gateway.
I’m seeing the same problem for https://cloudflare-ipfs.com/ipfs/QmTfXoED9voY5sT6Fmm1GhzJBriYrsXUw8Exd4Gzp3z9ue. Loading it in your browser you can see that only the first half of the image is returned. https://ipfs.io/ipfs/QmTfXoED9voY5sT6Fmm1GhzJBriYrsXUw8Exd4Gzp3z9ue returns the full image as expected.
Indeed, the link loads only half of the image for me. Cloudflare node in Sweden.
I’ve filled the ticket #2347312 to Cloudflare support. In fact, it was filled before my first forum post. I’ve updated the ticket with your URL.
Interesting. I am unlikely to be hitting the same edge as you so it looks like this issue is affecting multiple edge locations. Maybe they are doing tired caching or something or maybe it is a reproducible bug.
HTTP/1.1 200 OK
Date: Sun, 23 Jan 2022 21:10:47 GMT
Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
Vary: X-Ipfs-Secure-Gateway, Service-Worker, Accept-Encoding
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Set-Cookie: __cf_bm=REDACTED; path=/; expires=Sun, 23-Jan-22 21:40:47 GMT; domain=.cloudflare-ipfs.com; HttpOnly; Secure; SameSite=None
By the way, the image loads in full right now.
I saw this again with a CNAME site. This time the file was truncated all the way to 0 bytes!
% curl -i https://userscripts.kevincox.ca/gitlab-emoji.user.css
date: Sun, 06 Mar 2022 01:32:04 GMT
content-type: text/css; charset=utf-8
last-modified: Sat, 05 Mar 2022 23:33:21 GMT
vary: X-Ipfs-Secure-Gateway, Service-Worker, Accept-Encoding
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
set-cookie: __cf_bm=REDACTED; path=/; expires=Sun, 06-Mar-22 02:02:04 GMT; domain=.userscripts.kevincox.ca; HttpOnly; Secure; SameSite=None
My data experienced cut-off two more times. I’ve sent everything to the ticket.
I found this conversation because I have the same issue with this file:
Other gateways (fleek, ipfs.io, pinata) serve the file in its entirety.
One trouble is that some platforms like objkt.com uses Cloudflare ipfs gateway as the hardcoded way to display the original ipfs files if users want to see it (understandable, as most users don’t have ipfs desktop or a local node).
Is the bug considered as identified? Is there a tool to force recaching an ipfs file?
To add to this, the Cloudflare IPFS Gateway team have identified a bug and are working on a fix to be released shortly. We will provide more updates as they come!
A new version of our IPFS gateway has been released to address these issues. Please let us know if any errors are observed going forward.
Hi and thanks for the news Chris!
the file in question is now fine on my side / region.
I will check other files and report back if I have further issues
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.