Conversation
_send_file("") stats the current working directory, giving werkzeug a
complete_length of 4096 (Linux dir block size). When the browser sends
a Range header for video streaming, werkzeug rejects it with 416
because the requested byte offset exceeds 4096.
Strip HTTP_RANGE from the environ passed to werkzeug so it skips Range
validation. S3/nginx handle Range requests natively through the
X-Accel-Redirect path.
Contributor
|
Hi @lmignon, |
Author
|
not sure yet if this is due to network issues or large files |
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
2 participants
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.
Currently range requests are not working (for example in preview videos in Discuss application using firefox) early terminated with HTTP error 416
Media resource baseurl/mail/channel/340/attachment/56318 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_RANGE_ERR (0x806e0069)
Details: Result<already_AddRefed, MediaResult> __cdecl mozilla::SampleIterator::GetNext(void): Sample data read failed
Why fs_attachment and not fs_attachment_s3?
_fs_use_x_sendfile() checks fs_storage_id.use_x_sendfile_to_serve_internal_url — this is a generic flag on any fs.storage record, not S3-specific. The _send_file("") bug triggers for every backend (S3, local filesystem, SFTP, whatever) that has this checkbox enabled.
The flow is:
FsStream.get_response() in fs_attachment calls _send_file("") -> bug is here
fs_attachment_s3 only extends how the redirect URL is built, not the response creation
So fs_attachment is the correct place. Moving it to fs_attachment_s3 would leave the bug open for any other storage using X-Accel-Redirect.