Closed solracsf closed 2 years ago
Hmm.. I have no idea what to do about this (or even what it means).
We already close a CURL handle when we get any errors on it, so that logic is already in place.
You could try enabling -f --debug --http-debug
and sending the logs to the CURL team. Of course the logs could be voluminous so this would benefit from a minimal test case.
Hey @acsfer Same problem here when doing high write operations.
However I'm noticing one thing : We both use scaleway object storage, and I did not notice errors before recently. It could mean that the error is not directly from s3backer or curl, but maybe from Scaleway S3 itself (linked to the new multi-az bucket feature maybe ?)
AWS doesn't use HTTP/2, maybe there is a good reason to this ;) That's why we've disabled it. But maybe reach Scaleway on this (we are just testing).
After some investigation, and being on FreeBSD I re-compiled curl without the HTTP2 support and everything works fine. So I think the error indeed lies in Scaleway and its handling of HTTP2 (I heard that there was special behaviour on AWS with load balancers and such aswell.)
It's not a huge need for me, I use s3backer as a kinda-NAS only but I'll try and contact the support team nonetheless.
@archiecobbs I'm not sure about what power you have on this matter regarding libcurl, but would it be useful to fallback to http1.1 incase of such protocol errors ? I'm not sure about your software behaviour in this case, and I was afraid that some PUT would not go through and would be lost at some point.
@GreenBlood s3backer already closes the current CURL handle and retries on HTTP errors, so the impact of this issue should be minimal.
In any case I'm not sure what else there would be for s3backer to do anyway.
Some software (like rclone) has an option like --disable-http2
to handle these cases, by disabling it's negotiation (just like I did - see my 1st post). This is the only thing that could be done s3backer side (beside retries).
Feel free to close this as this is NOT a direct s3backer issue.
I've added --http11
to restrict CURL to HTTP 1.1. See if that works around the problem.
Perfect ❤️
I'm having quite a lot of
operation failed: Stream error in the HTTP/2 framing layer (will retry)
in my logs.This message comes from CURLE_HTTP2_STREAM and there are a few reports, all closed, on the curl repo. Some of them were fixed upstream, others on the program calling curl itself.
To exclude any bug in curl itself, I've compiled
curl
andnghttp2
from source to their latest releases, but errors remains.The only "workaround fix' was disabling HTTP/2 negotiation by setting
CURLOPT_SSL_ENABLE_ALPN
andCURLOPT_SSL_ENABLE_NPN
to 0 onhttp_io.c
Excerpt form
--debug
log (1sec window):