Bài 36: Multipart Upload: File + Field

Sau bài học, bạn sẽ:

• Hiểu multipart/form-data format và khác biệt với application/x-www-form-urlencoded ở B35 (boundary delimiter tách parts vs flat key=value percent-encoded).
• Biết Multipart extractor axum core stream từng field qua multipart.next_field().await không load toàn body memory.
• Nắm cách extract text field qua field.text().await và file field qua field.bytes().await.
• Áp dụng file size limit anti-DoS qua DefaultBodyLimit::max(N) per route — Shop API 5MB product image, 2MB avatar, 20MB PDF.
• Hiểu magic bytes verify MANDATORY — KHÔNG trust Content-Type/filename client gửi; dùng crate infer detect MIME từ bytes thật.
• Save file safe — generate UUID v4 server-side cho filename tránh path traversal, extension từ magic bytes (KHÔNG từ client filename).
• Pattern Shop API admin upload product image (B62 implement): Multipart → size limit → magic bytes verify → UUID filename → S3 + CDN URL (CDN strategy lock B27).

Khi HTML form khai báo enctype="multipart/form-data" hoặc có <input type="file" />, browser tự đổi Content-Type submit từ application/x-www-form-urlencoded (B35) sang multipart/form-data; boundary=----abc123 — format hoàn toàn khác để truyền file binary hiệu quả mà không phải encode toàn bộ thành base64 (tốn 33% size) hay percent-encoding (tốn 200% với byte non-ASCII).

Cấu trúc body chia thành parts tách qua boundary marker ngẫu nhiên do browser sinh (đảm bảo không trùng nội dung file). Mỗi part có:

• Header Content-Disposition: form-data; name="..." cho text field, hoặc thêm ; filename="..." cho file field.
• Header Content-Type: image/jpeg cho file field claim MIME (client gửi — KHÔNG trust cho security).
• 1 empty line phân tách header và body.
• Body part: text UTF-8 hoặc binary bytes raw.

Wire format đầy đủ cho form admin upload product image (1 text field + 1 file field):

POST /admin/products/upload HTTP/1.1
Host: admin.shop.com
Content-Type: multipart/form-data; boundary=----abc123
Content-Length: 524

------abc123
Content-Disposition: form-data; name="title"

Phone Pro
------abc123
Content-Disposition: form-data; name="image"; filename="phone.jpg"
Content-Type: image/jpeg

<binary jpeg bytes ~500KB...>
------abc123--

Quan sát chi tiết:

• Boundary ----abc123 ngẫu nhiên do browser sinh — bắt đầu mỗi part qua --{boundary}, kết thúc body qua --{boundary}-- (suffix double dash).
• Text field (title) chỉ có Content-Disposition: form-data; name="title", body là text UTF-8.
• File field (image) có thêm filename="phone.jpg" trong Content-Disposition + Content-Type: image/jpeg riêng + body binary bytes raw.
• Streaming-friendly — server có thể parse từng part lần lượt không cần biết trước Content-Length tổng, phù hợp file lớn không load full memory.

So với x-www-form-urlencoded B35: urlencoded flat title=Phone+Pro&image=... chỉ chứa text, file binary phải base64 encode (tốn 33% size + complexity decode), không streaming-friendly. Multipart sinh ra chính cho use case file upload theo RFC 7578.

axum cung cấp axum::extract::Multipart extractor có sẵn trong axum core (KHÔNG cần feature riêng axum-extra). Pattern parse stream từng field qua .next_field().await trả Option<Field> — None khi hết parts:

// File: crates/shop-api/src/routes/admin/products.rs (B62 implement)
use axum::extract::Multipart;
use axum::response::Json;
use shop_common::error::AppResult;

#[derive(serde::Serialize)]
struct UploadResponse {
    url: String,
    title: String,
}

async fn upload(
    mut multipart: Multipart,
) -> AppResult<Json<UploadResponse>> {
    let mut title = String::new();
    let mut image_bytes: Option<bytes::Bytes> = None;

    while let Some(field) = multipart.next_field().await? {
        let name = field.name().unwrap_or("").to_string();
        match name.as_str() {
            "title" => {
                title = field.text().await?;
                tracing::info!(title = %title, "got title field");
            }
            "image" => {
                let filename = field
                    .file_name()
                    .unwrap_or("unknown")
                    .to_string();
                let content_type = field
                    .content_type()
                    .unwrap_or("")
                    .to_string();
                tracing::info!(
                    filename = %filename,
                    content_type = %content_type,
                    "got image field"
                );
                image_bytes = Some(field.bytes().await?);
            }
            _ => continue,
        }
    }
    // process bytes (B62 implement đầy đủ verify + save)
    Ok(Json(UploadResponse {
        url: "https://cdn.shop.com/products/...".to_string(),
        title,
    }))
}

Điểm chú ý:

• mut multipart: Multipart — extractor consume body qua FromRequest (KHÔNG FromRequestParts), đặt CUỐI arg list theo lock B31 giống Form<T>/Json<T>.
• multipart.next_field().await trả Result<Option<Field>, MultipartError>. Stream parse từng part lần lượt — None báo hết parts (gặp boundary kết thúc --{boundary}--).
• field.name() trả Option<&str> tên field từ Content-Disposition: form-data; name="...", dùng để route logic xử lý field nào.
• field.file_name() + field.content_type() trả Option<&str> filename và Content-Type client claim — chỉ log/audit, KHÔNG dùng cho security decision (chi tiết bước 5).
• field.text().await consume field thành String UTF-8 — phù hợp text field nhỏ (title, alt_text, sort_order). Fail nếu bytes không phải UTF-8 hợp lệ.
• field.bytes().await consume field thành bytes::Bytes — phù hợp file binary. Cẩn thận memory — file 5MB tiêu thụ 5MB RAM cùng lúc, bound qua body size limit (bước 4).

Alternative cho stream-based read tiết kiệm memory hơn nữa: field.chunk().await trả chunk nhỏ ~8KB liên tục, xử lý streaming từng chunk (vd upload thẳng S3 multipart upload song song không hold full bytes RAM). Pattern phức tạp hơn, Shop API B62 dùng field.bytes() đơn giản vì file image <= 5MB acceptable hold memory ngắn.

Pitfall nghiêm trọng: client gửi 10GB file → server load full vào Bytes → OOM crash. Attacker spam 100 request song song mỗi request 10GB → datacenter bandwidth + memory + disk hết → server down (DoS). Không limit thì 1 attacker đủ đánh sập production.

axum mặc định body limit 2MB per request qua DefaultBodyLimit bật sẵn ở extractor body (Json, Form, Multipart, Bytes). Vượt limit → reject 413 Payload Too Large body rỗng theo RFC 9110 mục 15.5.14.

Override per route qua .layer(DefaultBodyLimit::max(N)) trên Router:

// File: crates/shop-api/src/routes/admin/products.rs (B62 implement)
use axum::extract::DefaultBodyLimit;
use axum::routing::post;
use axum::Router;

pub fn admin_product_routes() -> Router<crate::AppState> {
    Router::new()
        .route(
            "/admin/products/:slug/images",
            post(upload_product_image),
        )
        .layer(DefaultBodyLimit::max(5 * 1024 * 1024))  // 5MB
        .route(
            "/admin/users/:id/avatar",
            post(upload_avatar),
        )
        .layer(DefaultBodyLimit::max(2 * 1024 * 1024))  // 2MB
}

Pattern Shop API lock vĩnh viễn 3 ngưỡng theo loại upload:

┌─────────────────────┬──────────┬──────────────────────────────────────┐
│ Use case            │ Limit    │ Lý do                                │
├─────────────────────┼──────────┼──────────────────────────────────────┤
│ Product image       │ 5 MB     │ JPEG 4K compress quality 85 ~3-4MB   │
│ User avatar         │ 2 MB     │ Portrait 1080p compress đủ           │
│ PDF document        │ 20 MB    │ Invoice/contract đa trang (future)   │
│ CSV import          │ 50 MB    │ Bulk import catalog (future)         │
│ Default (no upload) │ 2 MB     │ axum core default đủ cho JSON body   │
└─────────────────────┴──────────┴──────────────────────────────────────┘

Quan sát:

• Reject 413 Payload Too Large tự động axum default khi body vượt limit — client thấy ngay lỗi không phải đợi upload xong rồi mới biết fail.
• Stream-based check incremental — axum count bytes khi đọc body, dừng ngay khi vượt limit không phải đợi load full → catch sớm tiết kiệm bandwidth + memory.
• Per route limit tránh dùng global limit lớn nhất chung — vd 50MB CSV import KHÔNG nên áp dụng cho mọi endpoint (endpoint khác bị tăng surface tấn công).
• Cấu hình ngoài hard-code ở B62 — load từ AppConfig env var SHOP_UPLOAD_MAX_IMAGE_BYTES để dev test với limit nhỏ hơn không phải sửa code; default 5MB lock vĩnh viễn.

Combination với RequestBodyLimitLayer global (lock B29 G15) ở app root: global cap 50MB cho mọi route bảo vệ baseline, per-route override nhỏ hơn cho endpoint không cần upload lớn. Per-route limit không phá được global (axum check global trước).

Anti-pattern nghiêm trọng: trust Content-Type header client gửi cho security decision. Attacker upload file shell.php đổi Content-Type thành image/jpeg qua tool như Burp Suite → server save với extension .jpg nhưng thực ra là PHP shell. Khi web server (Apache/Nginx) serve file kèm misconfig execute .jpg qua PHP handler (or attacker tìm bypass route) → Remote Code Execution. Tương tự KHÔNG trust filename extension .jpg vì client tự đặt tên gì cũng được.

Pattern fix MANDATORY: verify magic bytes (file signature ở N bytes đầu file) — chuẩn quốc tế File Signature Database. Mỗi định dạng file có signature cố định ở bytes đầu, không thể fake mà file vẫn hoạt động được:

┌──────────┬─────────────────────────────────┬──────────────────────────┐
│ Format   │ Magic bytes (hex)               │ Vị trí                   │
├──────────┼─────────────────────────────────┼──────────────────────────┤
│ JPEG     │ FF D8 FF                        │ 3 bytes đầu              │
│ PNG      │ 89 50 4E 47 0D 0A 1A 0A         │ 8 bytes đầu              │
│ GIF      │ 47 49 46 38                     │ 4 bytes đầu (GIF8)       │
│ WebP     │ 52 49 46 46 ?? ?? ?? ?? 57 45   │ "RIFF...WEBP" offset 0+8 │
│          │ 42 50                           │                          │
│ PDF      │ 25 50 44 46                     │ 4 bytes đầu (%PDF)       │
│ ZIP      │ 50 4B 03 04                     │ 4 bytes đầu (PK)         │
│ MP4      │ 00 00 00 ?? 66 74 79 70         │ offset 4 (ftyp)          │
└──────────┴─────────────────────────────────┴──────────────────────────┘

Crate infer 0.16+ detect MIME từ bytes tự động, hỗ trợ 100+ format. Pattern verify trong Shop API:

// File: crates/shop-api/src/upload/verify.rs (B62 tạo)
use shop_common::error::AppError;

/// Verify magic bytes match accepted image formats.
/// Returns extension string (jpg/png/webp) để build filename safe.
pub fn verify_image_magic_bytes(bytes: &[u8]) -> Result<&'static str, AppError> {
    let kind = infer::get(bytes).ok_or_else(|| {
        AppError::BadRequest("unknown file type".to_string())
    })?;

    match kind.mime_type() {
        "image/jpeg" => Ok("jpg"),
        "image/png" => Ok("png"),
        "image/webp" => Ok("webp"),
        other => Err(AppError::BadRequest(format!(
            "unsupported file type: {}",
            other
        ))),
    }
}

Shop API accept list lock vĩnh viễn cho product image:

• JPEG (image/jpeg) — phổ biến nhất, compress lossy hiệu quả cho ảnh photo.
• PNG (image/png) — lossless cho ảnh có transparency hoặc UI element.
• WebP (image/webp) — modern format compress tốt hơn JPEG 25-35%, support browser 95%+ 2026.

CẤM list lock vĩnh viễn:

• GIF — animation overhead + size lớn quá so với static image; nếu cần animation dùng video MP4 hoặc WebM optimized hơn nhiều.
• SVG — XSS risk nghiêm trọng vì SVG cho phép inline <script> tag và event handler onclick; khi serve cùng origin (cdn.shop.com) hoặc inline render, attacker upload SVG có JS đánh cắp cookie / phishing UI. Nếu cần icon vector dùng icon set sprite preload từ designer team, KHÔNG accept SVG upload runtime.
• Mọi format khác — exe, sh, php, html, zip, pdf — reject 400 Bad Request.

Workspace dependencies preview (B62 add khi implement):

# File: Cargo.toml workspace root (B62 add)
[workspace.dependencies]
infer = "0.16"
uuid = { version = "1", features = ["v4"] }
# aws-sdk-s3 hoặc object_store (TBD B62)

Anti-pattern nghiêm trọng: dùng filename client gửi qua field.file_name() trực tiếp save filesystem. Attacker gửi filename="../../../etc/passwd" hoặc filename="C:\Windows\System32\evil.dll" — nếu code naive concat upload_dir.join(filename) thì path resolve thành /etc/passwd hoặc system folder, overwrite file hệ thống → RCE / privilege escalation.

Ngay cả filename "bình thường" như photo.jpg vẫn rủi ro: 2 user upload cùng tên → collision overwrite; filename chứa ký tự đặc biệt (; & |) có thể command injection nếu code shell-out xử lý sau.

Pattern fix MANDATORY 2 lớp:

• CẤM dùng field.file_name() client trực tiếp cho filesystem path — chỉ log/audit value gốc để truy vết.
• Generate UUID v4 server-side cho filename qua crate uuid 1 feature v4 — entropy 122 bit collision negligible cross-instance.
• Extension từ magic bytes verify (bước 5) — KHÔNG từ client filename extension.

// File: crates/shop-api/src/upload/save.rs (B62 tạo)
use std::path::PathBuf;
use uuid::Uuid;
use bytes::Bytes;
use shop_common::error::AppResult;
use crate::upload::verify::verify_image_magic_bytes;

/// Build safe filename + path. Verify magic bytes trước.
/// Return tuple (filename string, full safe path).
pub fn build_safe_path(
    upload_dir: &PathBuf,
    bytes: &Bytes,
) -> AppResult<(String, PathBuf)> {
    let ext = verify_image_magic_bytes(bytes)?;  // magic bytes, KHÔNG client
    let filename = format!("{}.{}", Uuid::new_v4(), ext);
    let safe_path = upload_dir.join(&filename);
    // safe_path KHÔNG bao giờ chứa `..` hoặc path control character
    // vì UUID v4 chỉ chứa hex + dash, ext là hardcoded whitelist (jpg/png/webp)
    Ok((filename, safe_path))
}

Quan sát chi tiết:

• UUID v4 random 122 bit dạng 550e8400-e29b-41d4-a716-446655440000 — chỉ chứa hex digit + dash, không có path separator (/, \) hay ...
• Extension whitelist hardcoded jpg|png|webp trả từ verify_image_magic_bytes — KHÔNG bao giờ là arbitrary string client.
• upload_dir.join(filename) safe vì cả 2 component đều known-good — Rust PathBuf::join không expand .. nhưng filename không chứa .. anyway.
• Audit trail — vẫn lưu filename gốc client (field.file_name()) vào column original_filename DB cho truy vết, KHÔNG dùng cho filesystem path.

Workspace dependencies preview (B62 add):

[workspace.dependencies]
uuid = { version = "1", features = ["v4"] }

Tham khảo OWASP — Unrestricted File Upload nêu rõ 4 vector tấn công file upload: (1) magic bytes spoof Content-Type, (2) filename traversal, (3) double extension shell.php.jpg, (4) size DoS. 3 vector đầu mitigation qua bước 5 + 6 ở bài này, vector 4 qua bước 4 file size limit.

Sau khi verify magic bytes + build safe path, save file vào đâu? 2 lựa chọn theo môi trường:

Disk local — chỉ dev/local test:

// Dev only — KHÔNG dùng production
use tokio::fs;

async fn save_to_disk(
    safe_path: &std::path::Path,
    bytes: &bytes::Bytes,
) -> shop_common::error::AppResult<()> {
    fs::write(safe_path, bytes).await?;
    Ok(())
}

Lý do KHÔNG dùng disk local production:

• Không scale horizontal — file save pod A, pod B serve request đọc không có file → 404 lung tung.
• Mất file khi restart/redeploy — container ephemeral, volume mount không phải standard practice cho user content.
• Không CDN coverage — user fetch image cross-region latency 200ms+ thay vì 30ms qua CDN edge.
• Bandwidth app server — mỗi GET image hit app server cạnh tranh resource với handler API business logic.
• Backup phức tạp — phải backup riêng filesystem ngoài database.

S3 / Cloudflare R2 / Bunny CDN — production lock B27 CDN strategy:

// File: crates/shop-api/src/upload/storage.rs (B62 implement)
// Pseudo-code preview — B62 implement đầy đủ với aws-sdk-s3 setup
use bytes::Bytes;
use shop_common::error::AppResult;

pub struct S3Storage {
    client: aws_sdk_s3::Client,
    bucket: String,
    cdn_base_url: String,
}

impl S3Storage {
    pub async fn upload(
        &self,
        filename: &str,
        bytes: Bytes,
        content_type: &str,
    ) -> AppResult<String> {
        self.client
            .put_object()
            .bucket(&self.bucket)
            .key(format!("products/{}", filename))
            .body(bytes.into())
            .content_type(content_type)
            .send()
            .await?;
        Ok(format!("{}/products/{}", self.cdn_base_url, filename))
    }
}

Pattern Shop API CDN strategy lock B27:

• Upload → S3 bucket theo env: shop-uploads-dev, shop-uploads-staging, shop-uploads-prod.
• CloudFront / Cloudflare CDN front bucket — phục vụ user qua URL https://cdn.shop.com/products/{uuid}.jpg.
• Database lưu URL CDN trong table product_images (column url: TEXT), KHÔNG lưu bytes vào PostgreSQL (bytea query chậm + backup khổng lồ + transfer cost cao).
• Cache header CDN: Cache-Control: public, max-age=31536000, immutable vì filename UUID unique không bao giờ đổi nội dung (cache busting tự nhiên qua URL khác khi upload mới).

Crate lựa chọn (TBD lock B62):

• aws-sdk-s3 — official AWS SDK cho Rust, support full S3 feature (multipart upload, presigned URL, server-side encryption); dependency lớn ~30 crates transitive.
• object_store — multi-backend abstraction (S3/Azure Blob/GCS/local), interface đồng nhất swap backend không sửa code; dependency nhỏ hơn, lock Apache Arrow ecosystem.
• rusty-s3 — minimal S3 client signed-only, không async runtime lock-in, lightweight cho microservice.

Shop API lean về object_store để swap S3 dev/MinIO ↔ Cloudflare R2 prod không sửa code (R2 S3-compatible nhưng có quirk), lock cuối ở B62 khi implement.

Ghép 4 bước (extract → size limit → magic bytes verify → UUID filename → S3) thành endpoint admin upload product image — preview pattern B62 implement:

Endpoint lock: POST /api/v1/admin/products/:slug/images với RequireRole<"admin"> (B135 implement role-based access control).

Flow 7 bước:

1. Auth verify (B112) + role check admin (B135) qua extractor RequireRole<"admin">.
2. Multipart extract: image file field + optional alt_text text field.
3. Size limit check 5MB qua DefaultBodyLimit::max(5 * 1024 * 1024) route layer.
4. Magic bytes verify jpeg/png/webp qua infer::get.
5. Generate UUID v4 filename.
6. Upload S3 qua aws-sdk-s3 / object_store.
7. INSERT vào table product_images (B62 lock schema) + return Json<ImageDto> 201.

Code skeleton preview (B62 implement đầy đủ):

// File: crates/shop-api/src/routes/admin/products.rs (B62 implement)
use axum::extract::{Multipart, State};
use axum::Json;
use uuid::Uuid;
use crate::extractors::AppPath;
use crate::upload::{verify::verify_image_magic_bytes, storage::S3Storage};
use crate::AppState;
use shop_common::error::{AppError, AppResult};

#[derive(serde::Serialize)]
pub struct ImageDto {
    pub id: Uuid,
    pub url: String,
    pub alt_text: Option<String>,
}

pub async fn upload_product_image(
    State(state): State<AppState>,
    AppPath(slug): AppPath<String>,
    // _: RequireRole<"admin">,  // B135 implement
    mut multipart: Multipart,
) -> AppResult<Json<ImageDto>> {
    let mut image_bytes: Option<bytes::Bytes> = None;
    let mut alt_text: Option<String> = None;

    while let Some(field) = multipart.next_field().await? {
        match field.name().unwrap_or("") {
            "image" => {
                image_bytes = Some(field.bytes().await?);
            }
            "alt_text" => {
                alt_text = Some(field.text().await?);
            }
            _ => continue,
        }
    }

    let bytes = image_bytes.ok_or_else(|| {
        AppError::BadRequest("image field missing".to_string())
    })?;

    // Step 4: magic bytes verify (KHÔNG trust Content-Type/filename client)
    let ext = verify_image_magic_bytes(&bytes)?;

    // Step 5: UUID v4 server-side filename (KHÔNG dùng filename client)
    let filename = format!("{}.{}", Uuid::new_v4(), ext);

    // Step 6: upload S3 + get CDN URL
    let cdn_url = state.storage.upload(
        &filename,
        bytes,
        &format!("image/{}", ext),
    ).await?;

    // Step 7: INSERT product_images (B62 implement repo)
    let image_id = state
        .product_repo
        .add_image(&slug, &cdn_url, alt_text.as_deref())
        .await?;

    Ok(Json(ImageDto {
        id: image_id,
        url: cdn_url,
        alt_text,
    }))
}

Schema preview product_images (B62 lock đầy đủ):

CREATE TABLE product_images (
    id          UUID PRIMARY KEY,
    product_id  UUID NOT NULL REFERENCES products(id) ON DELETE CASCADE,
    url         TEXT NOT NULL,               -- URL CDN, không lưu bytes
    alt_text    TEXT,                        -- SEO + accessibility
    sort_order  INTEGER NOT NULL DEFAULT 0,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_product_images_product_id ON product_images(product_id);

Route mount với size limit + role check:

// File: crates/shop-api/src/routes/admin/mod.rs (B62 implement)
use axum::extract::DefaultBodyLimit;
use axum::routing::post;
use axum::Router;
use crate::AppState;

pub fn admin_routes() -> Router<AppState> {
    Router::new()
        .route(
            "/admin/products/:slug/images",
            post(products::upload_product_image),
        )
        .layer(DefaultBodyLimit::max(5 * 1024 * 1024))
        // .route_layer(RequireRole::<"admin">::new())  // B135
}

Wrapper pattern AppMultipart tương tự AppForm B35 (file path lock crates/shop-api/src/extractors/multipart.rs B62 tạo) — map MultipartRejection sang AppError envelope chuẩn:

// File: crates/shop-api/src/extractors/multipart.rs (B62 tạo - preview)
// Pattern thinner hơn AppForm vì Multipart không destructure T,
// chỉ wrap để consistent error envelope.
// Chi tiết implementation B62.

• multipart/form-data với boundary delimiter tách body thành parts (text field + file field), khác hoàn toàn application/x-www-form-urlencoded B35 (flat key=value percent-encoded); browser tự đổi Content-Type khi form có <input type="file" />.
• axum::extract::Multipart extractor axum core stream từng field qua multipart.next_field().await trả Option<Field>; đặt CUỐI arg list theo lock B31 (consume body).
• field.text().await cho text field UTF-8 → String; field.bytes().await cho file field → Bytes (cẩn thận memory, bound qua body size limit).
• Body size limit anti-DoS MANDATORY: DefaultBodyLimit::max(N) per route layer; Shop API lock vĩnh viễn 5MB product image, 2MB avatar, 20MB PDF (future), 50MB CSV import (future); reject 413 Payload Too Large axum default.
• Magic bytes verify MANDATORY: KHÔNG trust Content-Type/filename client gửi (attacker upload shell.php đổi Content-Type → RCE); dùng crate infer 0.16+ detect MIME từ N bytes đầu file (JPEG FF D8 FF, PNG 89 50 4E 47 0D 0A 1A 0A, WebP RIFF...WEBP).
• Path traversal prevention: generate UUID v4 server-side cho filename (CẤM dùng field.file_name() client tránh ../../../etc/passwd); extension từ magic bytes verify whitelist hardcoded (jpg/png/webp).
• Shop API accept lock vĩnh viễn cho product image: image/jpeg, image/png, image/webp. CẤM GIF (animation overhead) + CẤM SVG (XSS risk inline JS).
• Save destination: disk local tokio::fs::write CHỈ dev; production S3/Cloudflare R2/Bunny CDN theo CDN strategy lock B27 (REST API KHÔNG tự serve product image, database lưu URL CDN KHÔNG bytes).
• Pattern admin upload product image endpoint POST /api/v1/admin/products/:slug/images với RequireRole<"admin"> (B135) — flow 7 bước: auth → multipart extract → size limit 5MB → magic bytes verify → UUID filename → upload S3 → INSERT product_images table → return URL CDN (B62 implement đầy đủ).
• Workspace.dependencies preview B62 add: infer = "0.16" + uuid = { version = "1", features = ["v4"] } + aws-sdk-s3 hoặc object_store (TBD lock B62 khi implement).
• B36 conceptual + preview pattern, KHÔNG tạo file thực tế ở Shop API (Workspace State KHÔNG đổi). File crates/shop-api/src/extractors/multipart.rs wrapper AppMultipart + handler upload + workspace dep sẽ add ở B62.

Tự trả lời, đáp án ở cuối:

1. multipart/form-data khác application/x-www-form-urlencoded ở điểm gì? Tại sao browser tự đổi Content-Type khi form có <input type="file" />?
2. field.text().await vs field.bytes().await. Khi nào dùng cái nào? Memory implication ra sao với file lớn?
3. Tại sao KHÔNG trust Content-Type header client cho file upload? Attack vector cụ thể là gì? Pattern verify đúng dùng crate nào?
4. Path traversal attack với filename ../../../etc/passwd hoạt động ra sao? 2 mitigation strategies MANDATORY là gì? Tại sao UUID v4 safe?
5. Shop API product image: max size lock vĩnh viễn bao nhiêu? File type accept/cấm lock là gì và tại sao? Lưu vào đâu production và lý do?

Bài 37: Raw Body & Bytes Extractor — chi tiết Bytes extractor toàn body raw không parse, String UTF-8 extractor, max body size limit qua DefaultBodyLimit::max(N); use case quan trọng webhook signature verify (Stripe Stripe-Signature header HMAC SHA256 với raw body bytes, GitHub X-Hub-Signature-256 tương tự) — KHÔNG thể parse JSON/Form trước verify vì serde re-serialize sẽ khác bytes gốc làm signature không khớp; pattern đọc raw bytes trước verify HMAC, parse JSON sau khi verify OK; Shop API B197 Stripe webhook implement đầy đủ với idempotency Redis check tránh replay attack.