Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Body-parser errors always transformed to 500 #5191

Closed
tomasAlabes opened this issue Aug 1, 2020 · 5 comments
Closed

Body-parser errors always transformed to 500 #5191

tomasAlabes opened this issue Aug 1, 2020 · 5 comments
Labels
needs triage This issue has not been looked into

Comments

@tomasAlabes
Copy link

tomasAlabes commented Aug 1, 2020

Bug Report

Current behavior

If you send a payload that is too big for body-parser, it should respond with a HTTP code 413. But Nest'sBase Exception Filter is considering BP's exception as an unknown error, hence wrapping it in a 500 Internal Server Error.

Input Code

Vanilla Nest app with body-parser enabled. I can't paste the "too big" request.

Expected behavior

As body-parser and cors are part of Nest core functionality, the errors thrown by them should be honored by the app.

Possible Solution

Special check for cors/body-parser exceptions?
A special exception handler that comes with platform-express that understands express middleware?
Duck typing to see if the exception comes with a http status or error code?

Environment

Nest version: 7.4.2

For Tooling issues:

  • Node version: 12.18.3
  • Platform: Mac

Others:

Using @nestjs/graphql but it doesn't even get to that layer.

PayloadTooLargeError: request entity too large
    at readStream (/Users/path/to/repo/node_modules/raw-body/index.js:155:17)
    at getRawBody (/Users/path/to/repo/node_modules/raw-body/index.js:108:12)
    at read (/Users/path/to/repo/node_modules/body-parser/lib/read.js:77:3)
    at jsonParser (/Users/path/to/repo/node_modules/body-parser/lib/types/json.js:135:5)
    at Layer.handle [as handle_request] (/Users/path/to/repo/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/path/to/repo/node_modules/express/lib/router/index.js:317:13)
    at /Users/path/to/repo/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/Users/path/to/repo/node_modules/express/lib/router/index.js:335:12)
    at next (/Users/path/to/repo/node_modules/express/lib/router/index.js:275:10)
    at cors (/Users/path/to/repo/node_modules/cors/lib/index.js:188:7)
@tomasAlabes tomasAlabes added the needs triage This issue has not been looked into label Aug 1, 2020
@tomasAlabes tomasAlabes changed the title Body-parser always errors transformed to 500 Body-parser errors always transformed to 500 Aug 3, 2020
@tomasAlabes
Copy link
Author

From @jmcdo29 in discord:

this is something I've been thinking about since your raised the issue the first time. I could think of a way to make it work, but it may take me some time to getting some code for it. Until then, you could write your own Exception Filter that extends Nest's BaseExceptionFilter, or you could just write one from scratch 🙂

My filter until this is added to the framework: https://gist.github.com/tomasAlabes/249229f97e22774b4ab9682105ce2ca6

@makhataibar
Copy link

`
import { NextFunction, Request, Response } from 'express';
import { json, OptionsJson } from 'body-parser';

export const jsonBodyParser = (options?: OptionsJson) => (
req: Request,
res: Response,
next: NextFunction,
) => {
json(options)(req, res, err => {
if (err) {
res.status(err.status).json(err);
} else {
next();
}
});
};

`

@heavenkiller2018
Copy link

how to fix it ? "request entity too large"

@makhataibar
Copy link

how to fix it ? "request entity too large"

It’s custom body parser middleware

@kamilmysliwiec
Copy link
Member

Let's track this here #5990

@nestjs nestjs locked as resolved and limited conversation to collaborators Dec 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs triage This issue has not been looked into
Projects
None yet
Development

No branches or pull requests

4 participants