Asset upload refuses text/plain and application/json with "No file was sent." (REST and MCP upload_asset)

[fredcamaral]

Description

Uploading a file with Content-Type: text/plain or application/json fails with 400 No file was sent., both through POST /_api/sites/{siteId}/assets and through the MCP tool upload_asset. Other types work, text/csv, application/xml and application/x-yaml included. The route's own description says to "send the bytes with their Content-Type", and the upload_asset description says a text file can be sent as text, so this looks unintended.

Environment

• Wiki.js 3.0.1, ghcr.io/requarks/wiki:3 (sha256:6e9987cc7f0f583f73591fbdf318fe94c6ba76616913e6c8f833b7a1960cd31d), PostgreSQL 18.6, fresh install.
• API on, MCP on with the assets tool group enabled.
• A personal access token made in the profile with assets:write and mcp:write, owned by the admin. It has no OAuth client, so this is not Bug: MCP: comment, suggestion and glossary-write tools fail with "This token was granted to an MCP client and is accepted by /_mcp only" #8175.

Steps to reproduce

1. Call upload_asset on /_mcp with
   {"folder":"uploads","fileName":"data.json","mimeType":"application/json","text":"{\"a\":1}\n"}

2. Call it again with {"folder":"uploads","fileName":"notes.csv","mimeType":"text/plain","text":"a,b\n1,2\n"}.

3. Or call the REST route directly:

   curl -X POST -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
     --data-binary '{"a":1}' \
     "http://<host>/_api/sites/<siteId>/assets?fileName=data.json&folderPath=uploads"

Actual behavior

fileName	mimeType / Content-Type	Result
data.json	application/json (text or base64)	No file was sent.
notes.csv	text/plain (text or base64)	No file was sent.
notes3.csv	text/csv	stored
data3.json	application/octet-stream	stored, served as application/json
config.yaml	application/x-yaml	stored
page.xml	application/xml	stored
pixel.png, doc.pdf	image/png, application/pdf	stored

The REST call in step 3 answers {"ok":false,"error":"BadRequestError","statusCode":400,"message":"No file was sent."}. The same call with Content-Type: application/octet-stream stores the file.

(readme.txt is refused anyway, because txt is a page extension by default. That refusal has its own message and is not part of this report.)

Expected behavior

The file is stored. The route description already says the type served back comes from the file name's extension rather than from the request.

Cause

backend/api/assets.ts:156 registers the raw-body parser for '*'. Fastify (5.12.7 in the image) uses the catch-all only for content types that have no parser of their own, and it parses application/json and text/plain itself. For those two, req.body is an object or a string, Buffer.isBuffer(data) at line 294 is false, and the route answers No file was sent.. upload_asset passes the caller's mimeType through as the request Content-Type (backend/mcp/tools/assets.ts:251-258), so it hits the same check.

The File Manager also sends the browser's file type (fileToUpload.type) as the Content-Type (frontend/src/components/FileManager.vue:2151), so a .json file uploaded from the browser should fail the same way. I did not test that in a browser.

Suggested fix

Register the buffer parser for application/json and text/plain too, in an encapsulated plugin that holds only the upload route, so the JSON routes keep the default parsers. Fastify lets addContentTypeParser replace those two defaults. A smaller fix for the tool alone is to have upload_asset send application/octet-stream.

[ismaeelakin]

Your explanation matches the parser selection behavior. I checked it with a small Fastify 5.12.7 inject() reproduction: a catch-all buffer parser still receives neither application/json nor text/plain, because their built-in parsers win.

A scoped replacement for all three types works:

await app.register(async upload => {
  upload.addContentTypeParser(
    ['application/json', 'text/plain', '*'],
    { parseAs: 'buffer', bodyLimit: uploadMaxFileSize },
    (_req, body, done) => done(null, body)
  );

  // Register only the existing asset-upload POST here, keeping its
  // permission checks, preParsing hook, schema, and handler.
});

The important integration detail is to put the upload route itself in that child scope, leaving the ordinary JSON API routes outside it. Replacing the parsers in the current assets module's entire scope would also affect its JSON-consuming sibling routes. Fastify's parser documentation explains this encapsulation.

In the reproduction, I checked:

• JSON, plain text, CSV, and octet-stream uploads all arrive as buffers with the original bytes, including whitespace and the trailing newline.
• A sibling JSON route still receives a parsed object.
• Bytes labeled application/json but not valid JSON are accepted as file bytes on the upload route, without changing JSON validation elsewhere.
• The configured body limit still returns 413 for an oversized upload.

I would avoid recovering this by serializing an already-parsed req.body: that changes the original file bytes and cannot recover a JSON file the default parser rejected before the handler ran.

This verifies the Fastify mechanism and the proposed scope boundary; I have not run the complete Wiki.js upload/authorization pipeline. A full regression test should exercise the actual registered route, including its existing upload permission and size checks.

[NGPixel]

Fixed in 3.0.2

[ismaeelakin]

Thanks for fixing this, Nicolas. Good to know it's in 3.0.2. My check only covered the isolated Fastify parser behavior, so I haven't verified the release end to end. I'll leave that distinction here for anyone following the thread.