fix: enforce maxFileSize/maxTotalFileSize on octet-stream uploads

[spokodev]

The octet-stream upload path does not enforce the documented maxFileSize / maxTotalFileSize limits, unlike the multipart path.

Steps to reproduce

POST a 256KB body with Content-Type: application/octet-stream to a form configured with maxFileSize: 1024:

const form = formidable({ maxFileSize: 1024, maxTotalFileSize: 2048 });
form.parse(req, (err, fields, files) => {
  console.log(err, Object.keys(files).length);
});
// request.end(Buffer.alloc(256 * 1024, 0x42));

ACTUAL: err is undefined, one file is returned with size 262144, and the over-sized file is committed to disk via file.end().

EXPECTED: err.code === 1016 (biggerThanMaxFileSize), no file returned, and nothing left on disk. This matches how the multipart path already behaves.

Root cause

The octet-stream plugin's _parser.on("data", ...) handler in src/plugins/octetstream.js writes each chunk straight to the file with no size check, and it bypasses _handlePart() in src/Formidable.js where the multipart size caps are enforced. As a result a raw octet-stream body of any size is accepted regardless of the configured limits.

The README documents maxFileSize and maxTotalFileSize as limiting each file and the batch respectively, with defaults, and does not exempt octet-stream.

Fix

Accumulate the per-file and running total sizes before each write and abort via this._error(...) with the existing FormidableError codes biggerThanMaxFileSize / biggerThanTotalMaxFileSize when a cap is exceeded, mirroring _handlePart. In-limit uploads are unaffected. Because the octet-stream file is tracked in openedFiles, the shared _error cleanup calls file.destroy(), which unlinks the partial file, so no bytes remain on disk (the same cleanup the multipart path relies on).

Authority

CWE-770 (allocation without limits), plus the library's own documented contract and its multipart implementation, which enforces exactly these caps.

Tests

Added an integration case in test/integration/octet-stream.test.js: a 256KB octet-stream body with maxFileSize: 1024 must be rejected with code 1016 and return no files. Verified it fails on the current source (the over-sized upload is accepted with err null) and passes with the fix, with the tmp directory left empty afterwards.

Suite status: 92 passed / 3 skipped across 14 jest suites, and 11/11 node tests.

Greptile Summary

This PR closes a gap where application/octet-stream uploads bypassed the maxFileSize / maxTotalFileSize limits that the multipart path already enforces. The fix adds per-chunk size accounting in the octetstream plugin's data handler, erroring out with the existing FormidableError codes before any write occurs and relying on the shared _error() → file.destroy() cleanup path to unlink any partially-written file.

• src/plugins/octetstream.js: Accumulates fileSize and this._totalFileSize before each file.write() call; aborts with error code 1016 (biggerThanMaxFileSize) or 1009 (biggerThanTotalMaxFileSize) when a limit is exceeded, mirroring the guard already present in Formidable._handlePart.
• test/integration/octet-stream.test.js: Adds an integration test confirming that a 256 KB body sent with maxFileSize: 1024 is rejected with error code 1016 and leaves no files in the result set.

Confidence Score: 5/5

• Safe to merge — the change is narrowly scoped to the octet-stream data handler, uses the existing error and cleanup infrastructure correctly, and does not affect multipart or other upload paths.
• The size checks are gated before any file.write() call, so no bytes reach disk once a limit fires. Formidable.write() already guards subsequent chunks after this.error is set, making the handler's early return redundant but harmless. _error() is idempotent, file.destroy() is invoked via the existing openedFiles cleanup loop, and the endfn guard (if (this.error) return) ensures the parser's "end" event — and thus file.end() and the "file" emit — are never reached after an error. The integration test reproduces the documented failure scenario and confirms the fix.
• No files require special attention.

Important Files Changed

Filename	Overview
src/plugins/octetstream.js	Adds per-chunk maxFileSize and maxTotalFileSize checks before each file.write() call, using the correct FormidableError codes and mirroring the cleanup path already used by _handlePart. Logic is sound: Formidable.write() guards subsequent chunks after an error, and _error() is idempotent, so neither double-write nor double-error is possible.
test/integration/octet-stream.test.js	Adds an integration test that verifies a 256 KB octet-stream body is rejected with error code 1016 when maxFileSize: 1024. Exercises the biggerThanMaxFileSize path; the biggerThanTotalMaxFileSize (1009) path added to the source remains untested, but that thread was already resolved by the maintainer.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Pipe as pipe (Transform)
    participant FJ as Formidable.write()
    participant Parser as OctetStreamParser
    participant DH as data handler
    participant File

    Client->>Pipe: chunk N
    Pipe->>FJ: datafn(buffer)
    FJ->>FJ: if (this.error) return ← guard after first error
    FJ->>Parser: _parser.write(buffer) [sync PassThrough]
    Parser->>DH: emit("data", buffer)
    DH->>DH: "fileSize += buffer.length"
    DH->>DH: "_totalFileSize += buffer.length"
    alt "fileSize > maxFileSize"
        DH->>FJ: _error(FormidableError 1016)
        FJ->>File: file.destroy() [unlinks partial file]
        FJ-->>Client: "emits "error" → callback(err, fields, {})"
        DH->>DH: return (no write)
    else "_totalFileSize > maxTotalFileSize"
        DH->>FJ: _error(FormidableError 1009)
        FJ->>File: file.destroy()
        FJ-->>Client: "emits "error" → callback(err, fields, {})"
        DH->>DH: return (no write)
    else within limits
        DH->>FJ: this.pause()
        DH->>File: file.write(buffer, cb)
        File-->>DH: cb() → this.resume()
    end

Loading

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into fix/octetstre..." | Re-trigger Greptile}

[greptile-apps]

The two separate import statements can be merged into a single combined import, which is the pattern used throughout the codebase (e.g. import FormidableError, * as errors from "./FormidableError.js" in Formidable.js).

Suggested change

	import * as errors from "../FormidableError.js";
	import FormidableError from "../FormidableError.js";
	import FormidableError, * as errors from "../FormidableError.js";

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!