Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01VRLbHYdXVEBzGVhYq3pz4q
file-transfer
Companion code for File Upload and Download in Spring Boot 4: Multipart, Streaming and S3 Presigned URLs.
Spring Boot 4.1.1, Spring Framework 7.0.9, Tomcat 11.0.24, JDK 25, AWS SDK for Java 2.56.0. No Docker needed.
| Area | Code | What the run shows |
|---|---|---|
| Multipart limits | UploadController, UploadErrors, MultipartLimitsTest |
the 1 MB / 2 MB limits are enforced by Tomcat, so MockMvc accepts a file the real server rejects; the rejected-upload race (cap/01-limits.txt) |
| Filenames | FileStore, FilenameAndDownloadTest |
getOriginalFilename() is whatever the client sent, including ../../; the file is stored under a UUID (cap/02-filename.txt) |
| Download | DownloadController |
Resource gives Range/206/416 for free; Content-Disposition encoding (cap/03-download.txt) |
| Presigned URLs | S3PresignService, PresignController, FakeS3, PresignedUrlTest |
what is and is not covered by the signature; expiry; reuse (cap/04-presign.txt) |
| Streaming | StreamController, scripts/run-all.sh |
200 MB download and a 150 MB upload under -Xmx64m (cap/05-streaming.txt, cap/06-big-upload.txt) |
./scripts/run-all.sh # tests, then the -Xmx64m experiments; rewrites cap/*.txt
What was and was not run
- The presigned URLs are produced by the real AWS SDK presigner and checked by
FakeS3, a small in-process server that recomputes the AWS Signature V4 query signature from the published algorithm. That proves the URLs are consistent with the algorithm as documented. It does not prove a real S3 or MinIO server accepts them: this environment has no Docker and no S3-compatible server, so nothing here was run against one. app.s3.access-keyandapp.s3.secret-keyare the example keys from the AWS documentation. They are not credentials.