Conversation
Traefik v3 limits reading a whole request, body included, to 60s by default, and neither compose file changed it. The web client uploads in 64MB chunks, so any chunk a link cannot deliver within a minute was cut off mid-body and the multicam upload failed. On a ~2.75 MB/s link shared by five parallel uploads, the 26MB RGB frames of a KAMERA flight did exactly that. Set respondingTimeouts.readTimeout on the web (dev) and websecure (prod) entrypoints to TRAEFIK_READ_TIMEOUT, default 600s -- enough for a 64MB chunk at ~0.1 MB/s while still bounding a stalled client.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Traefik v3 limits reading a whole request, body included, to 60s by default, and neither compose file changed it. The web client uploads in 64MB chunks, so any chunk a link cannot deliver within a minute was cut off mid-body and the multicam upload failed. On a ~2.75 MB/s link shared by five parallel uploads, the 26MB RGB frames of a KAMERA flight did exactly that.
Set respondingTimeouts.readTimeout on the web (dev) and websecure (prod) entrypoints to TRAEFIK_READ_TIMEOUT, default 600s -- enough for a 64MB chunk at ~0.1 MB/s while still bounding a stalled client. Videos get through because they don't have the default batch-5 upload, so this is a corner case of an image sequence with large images on a slow network connection.