@zgramming can you please share:

1. request as curl
2. configuration of the middleware

Thx

@TheDadi

1. curl

curl --location --request POST 'http://localhost:6969/cv/preview/testing' 

2. config middleware

import Koa from "koa";
import KoaBody from "koa-body";
import Json from "koa-json";
import Logger from "koa-logger";
import passport from "koa-passport";
import session from "koa-session";
import Serve from "koa-static";

import cors from "@koa/cors";

import router from "./router";

const app = new Koa();

require("dotenv").config();
require("./utils/passport");

/// Passport initialize
app.keys = [process.env.KOA_SESSION_SECRET ?? ""];
app.use(session({}, app));
app.use(passport.initialize());
app.use(passport.session());
app.use(
  KoaBody({
    multipart: true,
  })
);

app.use(cors());
app.use(Json());
app.use(Logger());

/// Make folder file accessible via url
app.use(Serve("./public"));

app.use(router.routes()).use(router.allowedMethods());

app.listen(process.env.PORT, () => {
  console.log("Koa server is started on " + process.env.PORT);
});

@zgramming

Your not passing any content-type header and no data, that means it parses nothing at all. Version 5 used to give you back an empty object which v6 is not anymore.

isJson, isText, isUrlencoded, isMultipart are all falsy

@MarkHerhold should we add back this behavior since we do the same if the request method does not match parsedMethods? I created a pr that changes back the empty object behavior. Or should we remove the empty object also for non matching parsedMethods that the body always gets undefined if it matches neither parsedMethods and no content-type

@zgramming

The behavior for version 6.x is different, but in my opinion you should anyways do some validations on the body before destructuring and give back a http 400 if it doesn't match.

@TheDadi IMHO I think revert back old behaviour version 5 good option, because maybe we can have some request can be optional/undefined 😀.

Hey everyone,

I recently ran into this issue, and was about halfway into fixing it on my fork when I found this issue+PR. I have extended the previous proposed solution by adding a new config option, that would default to the "new" behavior (undefined body), while allowing support for the old behavior (empty object body).

Restoring the old behavior would be simpler, ofc, but since this is already live, someone might be relying on it, so having a config option adds complexity but should also keep everyone happy.

Kudos to @TheDadi for the original PR, whose code I copy-pasted into my commit, and extended.

Let me know your thoughts.

@MarkHerhold Since you seem very busy at the moment, would it be possible to talk about how to get a maintainer of this repo and help you out?

@MarkHerhold ping ☝️