Any idea why?

I believe the second part is responsible, cause IP filtering seems broken

oh nice

Do you happen to use IP filtering with an IPV4 address?

you mean for R2 API keys?

Yes

iirc I had trouble with it

damn, so there must be a bug then

Works fine for me, just tested it. The CF API supports IPv6, so if your server has IPv6 too, it's probably preferring it and using it. Make sure to whitelist your server's IPv6 range as well

Nop :(

Thanks for the response though.

> my server can't connect What error does it give?

oh, I see it there, 500

I had an issue like this a while ago before being hired, I believe @Harshal was the one looking at it for me

I just remember giving up.

You're using rclone? Any luck if you append --bind={your_ipv4} to the end of your command?

Would only work on a server with that IP bound to an interface I suppose, not if you were behind nat It looks like it doesn't work over IPv6 at all, even if I whitelist my server's entire range or force it to bind to a single IPv6 and whitelist that single IPv6. Not sure if I'm doing something wrong on my end or it's delayed to update, but it works fine whitelisting and binding to an IPv4

Yea I’m using rclone

hi i had a question regarding writing to R2 using a put request, i have cases of streaming writes where i cannot know the size of the file in advance (it's never larger than a few megabytes tho), so i cannot set a content-length header, but it seems R2 enforces content-length to be set

is there something that can be done?

You don't know the size of the file from whatever is sending you the stream either?

no i don't know the size

i could buffer the entire file before uploading it, but that kinda defeats the purpose

for context, this works with my current object storage provider

i'm considering moving to R2 and just making sure all the features i need are supported

this isn't a R2 specific thing. for any POST/PUT/PATCH HTTP operations you need a content length header - https://httpwg.org/specs/rfc9110.html#field.content-length

the same goes if you are streaming data; you still need to tell the server how much you are sending and in what fashion.

So never got a response about this and have been dealing with a lot of users running into the same thing again this week. Have done some debugging to make sure the 499 response is indeed coming from Cloudflare (it is) and not generated in my http client. So I'll pose the question again... how exactly is the client receiving a response from Cloudflare telling it that it disconnected before it disconnected? I've set the timeout on my end to something absurdly low and it's a different error ("Operation timed out") with the http client. I've also set it to something absurdly high (300 seconds to fetch a 1MB object) and still occasionally get an HTTP 499 from R2 long before 300 seconds have passed (usually after a few seconds). It feels to me like the 499 being given is actually a 5xx error (server-side, not client-side).