Client-side chunking
The browser slices a file into upload chunks and hashes them outside the main UI path. The server validates each chunk before it enters storage, then assembles a manifest when the file becomes visible.
No full-file buffering
Large files do not need to turn into a memory event.
Cotton's upload path is built so file size mostly changes the number of chunks, not the shape of the memory problem. That is the difference between streaming storage and a UI that stalls during finalization.
No giant finalize step
A common bad experience is fast upload followed by a long server-side finalization phase. Cotton shifts the expensive shape toward incremental chunk work, so the final visible file operation can stay small.
Streaming transforms
Compression and encryption run as streaming stages. They do not require the whole file to be present in memory before useful work starts, and they do not need to write a huge temporary plaintext object first.
WebDAV path
Even protocol uploads through WebDAV can land in the same chunk storage model. WebDAV PUT is not as resumable as Cotton's native chunk protocol, but it does not need a separate whole-file storage design.
Reads and previews
The same idea applies on read: a seekable stream can assemble bytes from encrypted chunks. Downloads, video seeking, preview extraction, and HTTP range responses do not need to rebuild the whole object first.
Why it matters
This is not only about huge files. Avoiding full-file buffering also helps normal folders, uploads from weaker devices, NAS deployments, low-memory VMs, and multi-user instances under concurrent load.
Streaming path proof
The no-buffering story depends on client chunking, worker hashing, incremental server validation, streaming compression, streaming AES-GCM, manifest assembly, and seekable chunk reads for download and preview paths.
Big files stay boring
Cotton treats big files as more chunks, not a special emergency path. That is the practical difference between a file cloud built for archives and one that only looks good on small uploads.
Other limits still exist
No full-file buffering does not remove every deployment limit. Operators still need sane request limits, storage capacity, network reliability, browser compatibility, and quota policy.
FAQ
Direct answers
Can Cotton upload very large files?
The architecture is chunk-first, so very large files are represented as more chunks and a manifest. Real limits still depend on deployment settings, browser behavior, storage backend, and network conditions.
Does WebDAV get the same native resume behavior?
No. WebDAV PUT is a long-lived protocol request, so retry behavior is naturally narrower than Cotton's native chunk protocol. It still enters the same chunked storage pipeline once received.
Does the no-buffering model help reads too?
Yes. Downloads, previews, media seeking, range requests, and WebDAV reads can be assembled from chunks as streams instead of rebuilding a whole temporary file first.