Incompatibility with RUFH protocol clients

Hi, I’m an Immich developer trying to improve the Cloudflare Tunnel experience for Immich. As a way to back up larger assets while respecting the 100MiB size limit, I’ve implemented the IETF-proposed RUFH spec supported by iOS’s URLSession client. This protocol allows clients to resume interrupted uploads when resumability can be negotiated with the server.

However, as clients still indicate the Content-Length of the full resource, it results in an immediate 413 response with no upload progress. It would be ideal to a) allow streaming the request body to the server up to the size limit and b) allow the server to respond to the client in this case. The goal is to receive the first 100MiB of the body and let the client know it can resume with the next chunk of data. Otherwise, it seems the major RUFH clients are simply unable to work well with Cloudflare services affected by this limit. For more context, this is the branch implementing the RUFH server: https://github.com/immich-app/immich/pull/22385

GitHub

feat(server): resumable uploads by mertalev · Pull Request #22385 ...

This is a PR to support resumable uploading using an in-built implementation of the IETF-proposed RUFH protocol. It will only implement the server side as client support is better addressed in sepa...

Mmertalev Hi, I’m an Immich developer trying to improve the Cloudflare Tunnel experience f...

Laudian•10/14/25, 11:14 PM

I mean, the point of the 100MB limit kinda is to make it not work with larger files.

I really doubt Cloudflare is going to help you circumvent their own free plan limits.

mertalevOP•10/14/25, 11:20 PM

I wouldn't assume that given the 100MiB limit is per-request. If the goal were to prevent significant upload traffic, the limit would be designed to span across requests. There may be other reasons for the limit, like the amount of memory needed for a given worker node, etc.

Chaika•10/14/25, 11:38 PM

This doesn't sound like anything specific to resumable uploads, it legitimately tries to upload the entire file in one request, so Cloudflare's limits are as normal. You'd have to multipart and split before the upload limit

mertalevOP•10/14/25, 11:42 PM

The current trend of the RUFH clients and draft proposal is to treat chunking as being a server-driven event. The server determines limits and forces the client to resume. The reasoning is that RUFH is a process of upgrading a conventional upload to a resumable one, and hence pre-chunking and such is a different paradigm that is not backwards compatible with this upload strategy

mertalevOP•10/14/25, 11:49 PM

For discussion on this in the IETF HTTP Working Group, you can look at https://github.com/httpwg/http-extensions/pull/3011 and https://github.com/httpwg/http-extensions/issues/3193

GitHub

Resumable Upload: Require client to adhere to limits in `Upload-Lim...

Currently, the client is not required to adhere to limits announced in the Upload-Limit header field in responses. As discussed in #3006 (comment), it doesn&#39;t make a lot of sense to give th...

GitHub

RESUMABLE: feature request - chunk granularity · Issue #3193 · ht...

The authors received an off-list message from a server implementer. They have an existing resumable upload deployment based on a custom protocol and are working to integrate support for draft-ietf-...

Mmertalev The current trend of the RUFH clients and draft proposal is to treat chunking as...

Chaika•10/15/25, 1:15 AM

ah ok interesting, so the server would just have to know of Cloudflare's upload limit, or maybe using a cloudflare worker inbetween to handle some of the request/response.
From those, it looks like you could maybe even just overwrite the Upload-Limit response header with Cloudflare Transform Rules to get it to constrain itself to be lower

mertalevOP•10/15/25, 1:17 AM

I’d like to make the server do that, but it can’t if the request is rejected before it even reaches the server

Chaika•10/15/25, 1:17 AM

oh, I thought from the spec there was a request first made without uploading to get those limits

Chaika•10/15/25, 1:20 AM

well regardless, The root of this seems to still be the same, other then limiting the request size itself, this is just tied to the normal cdn request limits.

As you noted, the limits are per request, Cloudflare used to buffer the entire request on their edge machine first before delivering it. The original reason given by the team were for slowloris mitigations: https://community.cloudflare.com/t/streaming-a-request/14724/4
However did this change recently with Cloudflare's rewrite of their request processing, https://blog.cloudflare.com/20-percent-internet-upgrade/, which does stream the request to the server rather then buffer entirely (although currently undocumented afaik). This is still rolling out though. It's possible with this, the limits may expand. On discord, there cdn team isn't in here, so your forums post is the best way to potentially have that team look at it. I would def wager this is way more long term though, but we'll see.

CChaika oh, I thought from the spec there was a request first made without uploading to ...

mertalevOP•10/15/25, 1:22 AM

The client is allowed to include data in the initial request. They can do an empty upload creation request first, but since it requires feature detection or knowing the server supports RUFH, in practice they use the create + append request strategy and check for an interim response from the server

CChaika well regardless, The root of this seems to still be the same, other then limitin...

mertalevOP•10/15/25, 1:22 AM

That’s interesting, I did notice that the request is streamed when limited to <= 100MiB, but it was buffered when I tried proxying the request through a worker

Mmertalev That’s interesting, I did notice that the request is streamed when limited to <=...

Chaika•10/15/25, 1:24 AM

I tested just now with a simple proxy on an enterprise (old platform) setup vs a free and manually rolled into new platform setup, and it def 100% streams on the new platform regardless of size, and old is buffered.

It is very possible that the Worker in the middle messes with things or makes it revert back to the old platform in the request (talked about a bit in the blog), they're still rolling out the new platform

mertalevOP•10/15/25, 1:27 AM

Thanks for that context! I hope the streaming rollout makes it more feasible to let the server handle these requests instead

Ramon "9Tails" Canales•11/24/25, 7:58 AM

Has there been any progress on this topic @Chaika ?

Ramon "9Tails" Canales•12/2/25, 1:38 PM

@Chaika ?

RRamon "9Tails" Canales @Chaika ?

Chaika•12/2/25, 2:02 PM

On upload limit? Nothing's changed as far as I'm aware of

Ramon "9Tails" Canales•12/2/25, 2:04 PM

I mean the streaming rollout. Cause that would fix no?

Ramon "9Tails" Canales•12/2/25, 2:04 PM

Or at least unblock

RRamon "9Tails" Canales I mean the streaming rollout. Cause that would fix no?

Chaika•12/2/25, 2:05 PM

the new platform behavior I was talking about above? No, it has the same upload limit

Ramon "9Tails" Canales•12/2/25, 2:07 PM

@mertalev what would help here?

mertalevOP•12/2/25, 3:07 PM

If the streaming rollout meant the first 100MB could reach the server, that would be pretty helpful. Itâd be particularly useful if the server could respond instead of the CDN as well

Ramon "9Tails" Canales•12/4/25, 12:52 PM

Is this the case @Chaika ?

Incompatibility with RUFH protocol clients

Similar Threads

Similar Threads

Similar Threads