File Upload and Download Integrity#

Two distinct integrity risks exist in Dify's file pipeline:

1. Upload — silent stream truncation: Most upload controllers call file.stream.read() without first calling file.stream.seek(0). If any middleware or validation code has advanced the stream position, the read silently returns a partial payload; no error is raised and the truncated bytes are committed to storage with an equally-truncated size recorded in the DB.

2. Download — Content-Length / actual-size mismatch: Download responses set the Content-Length header from the UploadFile.size database column with no verification against the bytes actually stored in the backend. A bug in upload_text previously stored character count (len(text)) rather than byte count, poisoning the DB value for non-ASCII uploads; this was fixed in PR #40034, though historical records may still contain incorrect metadata.

Upload: Silent Stream Truncation#

Pattern#

The plugin upload endpoint reads the stream directly without first seeking to position 0 1:

file_binary=file.stream.read(),

The same unseek'd file.stream.read() pattern appears in at least six other controllers:

• api/controllers/service_api/app/file.py 2
• api/controllers/console/files.py 3
• api/controllers/web/files.py 4
• api/controllers/openapi/files.py 5
• api/controllers/service_api/dataset/document.py 6

Because read() returns bytes from the current stream position, any upstream code that advances the cursor produces a silently-truncated payload. The downstream storage call succeeds, and len(file_binary) records the truncated size as ground truth in UploadFile.size — with no exception, no log warning.

Downstream path#

FileService.upload_file computes size as file_size = len(content) where content is the bytes already read from the stream. ToolFileManager.create_file_by_raw does the same (size=len(file_binary)). Both methods faithfully record whatever bytes they received — the corruption is silent and upstream.

Safer counter-pattern#

AnnotationBatchImportApi is the only controller with explicit stream position management 7:

file.stream.seek(0, 2) # seek to end to determine size
file_size = file.stream.tell()
file.stream.seek(0) # reset to beginning before reading

All other upload controllers should follow this pattern.

PR context#

PR #35985 standardized all controllers from file.read() to file.stream.read() across the console, service-api, web, and openapi namespaces, but did not add seek(0) guards. The vulnerability pattern is now uniformly present across the codebase.

Download: Content-Length Mismatch#

Header sourced from DB metadata#

FilePreviewApi.get sets the response header unconditionally from the database column:

if upload_file.size > 0:
    response.headers["Content-Length"] = str(upload_file.size)

upload_file.size is the value persisted at upload time — never re-validated against the storage backend. If the stored file has changed size (storage corruption, manual intervention, or silent truncation from an upload bug), the header is wrong. Clients relying on Content-Length for range requests, progress bars, or integrity checks receive incorrect data.

upload_text recorded characters, not bytes (fixed in PR #40034)#

FileService.upload_text previously saved text.encode("utf-8") to storage but recorded size=len(text) — the Unicode character count, not the UTF-8 byte length. For any text containing multi-byte characters (CJK, emoji, accented Latin), the DB size was smaller than the actual stored file. Content-Length would be under-reported on downloads, causing clients to treat the transfer as complete before all bytes were received.

PR #40034 fixed this by encoding the text once, saving those bytes, and using len(content) for the size — consistent with FileService.upload_file, which already used file_size = len(content) where content is bytes.

Note: Historical UploadFile records created before this fix may still have incorrect size metadata for non-ASCII text. The upload process itself now correctly stores UTF-8 byte lengths.

Affected Endpoints Summary#

Key Source Locations#