octet-stream uploads send base64 text instead of raw bytes, corrupting binary CAD uploads

[sneg55]

Octet-stream upload endpoints send base64 text instead of raw bytes, corrupting binary CAD uploads

Context: API Makeathon participant. Found while reviewing the file upload endpoints.

Endpoints that upload with Content-Type: application/octet-stream force body: string and generate readFile(..., 'base64'), then pass that base64 string straight to fetch. Base64 is an encoding of the file, not the original octets, so fetch transmits the ASCII bytes of the base64 text rather than the file's bytes. The body: string typing also rejects the correct Buffer, Uint8Array, or Blob inputs.

Evidence

gen/apiGen.ts:401 (the generator forces body: string and base64 for octet-stream), src/api/file/create_file_mass.ts:11 (passes the base64 string to fetch), and the README example at README.md:22.

Concrete failure

A binary CAD model arrives corrupted. Bytes [0, 255, 1, 2] become the base64 string "AP8BAg==", and fetch sends the eight ASCII bytes [65, 80, 56, 66, 65, 103, 61, 61] instead of the four original bytes, so the server parses garbage or rejects the file. Every octet-stream upload (mass, volume, and similar file endpoints) is affected.

Verify

const b = Buffer.from([0,255,1,2]);
const s = b.toString("base64");           // "AP8BAg=="
console.log([...b], s, [...Buffer.from(s,"utf8")]);
// [0,255,1,2] "AP8BAg==" [65,80,56,66,65,103,61,61]

Suggested fix

For octet-stream bodies, accept and forward the raw bytes (Buffer / Uint8Array / Blob / ReadableStream) to fetch instead of reading the file as a base64 string.

Environment

Reviewed against the current main of KittyCAD/kittycad.ts.