fix: use correct Content-Type in file-preview endpoint for non-download requests#37553
Open
GautamKumarOffical wants to merge 1 commit into
Open
Conversation
…ad requests
The /files/{file_id}/file-preview endpoint was unconditionally overriding
Content-Type to application/octet-stream, even for preview requests where
as_attachment is false. This caused browsers to force-download files instead
of rendering them inline (e.g., images, PDFs).
The fix moves the Content-Type override inside the as_attachment guard so it
only applies when the client explicitly requests a download.
Fixes langgenius#37198
GautamKumarOffical
requested review from
QuantumGhost and
laipz8200
as code owners
dosubot
Bot
added
the
size:XS
Contributor
Pyrefly Type Coverage
|
Author
|
Hi! This PR fixes a content-type issue in the file-preview endpoint. All checks are passing. Happy to make any adjustments. Thanks for reviewing! |
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.
Problem
The
/files/{file_id}/file-previewendpoint was unconditionally overridingContent-Typetoapplication/octet-streamon every response, regardless of whether the request was a preview or a download.This meant that when users tried to preview images or PDFs inline in the browser, the browser received
Content-Type: application/octet-streamand was forced to download the file instead of rendering it. This was a regression from v1.12.1 where the correct MIME type was returned.Root Cause
In
api/controllers/files/image_preview.py:135, the line that setsContent-Typetoapplication/octet-streamwas outside theif args.as_attachment:guard, so it ran for every request — both preview and download.Fix
Moved the
Content-Typeoverride inside theas_attachmentguard so it only applies when the client explicitly requests a download. For preview requests, the correct MIME type (set via themimetypeparameter when constructing the FlaskResponse) is preserved.Testing
Updated the existing unit test in
test_image_preview.pyto expect the correct MIME type (text/plain) for non-attachment preview requests, rather than the incorrectapplication/octet-stream.Fixes #37198