Skip to content

File Upload

This document describes the file upload process in Cloudreve. The upload flow varies depending on the storage policy type, but generally follows a three-step process.

Overview

A complete file upload consists of three steps:

  1. Create upload session - Request an upload session from Cloudreve server
  2. Upload chunks - Upload file data in chunks to the storage provider
  3. Complete upload - Finalize the upload (for some storage policies)

For small files, consider using the Update file content API for a simpler single-request upload.

Step 1: Create Upload Session

Use the Create upload session API to initiate an upload. The response includes:

  • session_id - Unique identifier for this upload session
  • chunk_size - Size of each chunk in bytes
  • upload_urls - Pre-signed URLs for uploading chunks (varies by storage policy)
  • credential - Authentication credential for chunk uploads
  • expires - Session expiration timestamp
  • storage_policy - Storage policy configuration including:
    • policy_type - Type of storage provider
    • chunk_concurrency - Maximum concurrent chunk uploads allowed
    • streaming_encryption - Whether streaming encryption is supported
  • encrypt_metadata - Encryption parameters (if client-side encryption is enabled)

Step 2: Upload Chunks

The chunk upload method depends on the storage policy type:

Local / Remote Storage Policy

For local storage, or any storage policy with storage_policy.relay set to true, use the Upload file chunk API.

For remote (slave node) storage, send chunks to the URL in upload_urls (single element). The request format is similar to the local chunk upload, with these differences:

  • Chunk index is passed via query parameter chunk, e.g., http://slave.example.com/api/v4/slave/upload/{session_id}?chunk=2
  • Authorization header uses the credential value from the upload session, e.g., Bearer Cr sBnnQ3rZ-UBr7d8ohKpUFtsQc8OMLuWwn1VhuJtdc5k=:1749623351

S3-Compatible Storage Policies

For S3, OSS, COS, OBS, and KS3 storage policies, use the pre-signed URLs in upload_urls (one URL per chunk). Refer to the respective cloud provider's multipart upload documentation:

OneDrive

For OneDrive storage policy, use the upload URL from upload_urls with byte range headers. Refer to Microsoft's Upload bytes to the upload session documentation.

Qiniu

For Qiniu storage policy, refer to Upload Part documentation.

Upyun

For Upyun storage policy, refer to Large File Upload documentation.

Step 3: Complete Upload

The completion step varies by storage policy:

Storage PolicyCompletion Method
Local / Remote / UpyunAutomatic - no action required after last chunk
OneDriveComplete OneDrive upload
S3 / KS3CompleteMultipartUpload, then Complete S3 upload callback
OSSCompleteMultipartUpload (callback handled automatically)
COSComplete Multipart Upload, then Complete COS upload callback
OBSCompleting a Multipart Upload, then Complete OBS upload callback
QiniuComplete Multipart Upload

Chunked Upload

Files are split into chunks based on the chunk_size returned by the upload session. The chunk_concurrency field in the storage policy specifies how many chunks can be uploaded simultaneously.

Client-Side Encryption

When file encryption is enabled on the server, the upload session response includes encrypt_metadata containing:

  • cipher - Encryption algorithm (e.g., aes-256-ctr)
  • key_plain_text - Base64-encoded encryption key
  • iv - Base64-encoded initialization vector

The client should encrypt file data using AES-256-CTR mode before uploading. With streaming encryption, chunk boundaries don't need to align with AES block boundaries - calculate the correct counter offset for each chunk based on its byte position in the file.

Reference Implementation

For a complete implementation reference, see: