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

500 error when content-type header is not formatted correctly #24768

Closed
jkjustjoshing opened this issue May 3, 2021 · 2 comments · Fixed by #24818
Closed

500 error when content-type header is not formatted correctly #24768

jkjustjoshing opened this issue May 3, 2021 · 2 comments · Fixed by #24818
Labels
good first issue Easy to fix issues, good for newcomers
Milestone

Comments

@jkjustjoshing
Copy link

What version of Next.js are you using?

10.2.0

What version of Node.js are you using?

14.16.1

What browser are you using?

Chrome

What operating system are you using?

Codesandbox

How are you deploying your application?

next start

Describe the Bug

When a request comes in to a pages/api endpoint, and the content-type header is not correctly formed, my API code does not run, and the request returns a 500 error.

I noticed this issue because I'm getting 500 responses for calls with a trailing semicolon in my production logs "content-type": "application/x-www-form-urlencoded;"

This does not happen for getServerSideProps calls.

content-type values that reach my code (and return 200 in the below reproduction):

  • text/plain
  • text/abcdefg
  • abc/defg
  • abc/___
  • abc/---

content-type values that do not reach my code and always return a 500 error:

  • text (anything without a slash)
  • /text and text/ (slash not in middle)
  • text/plain; and text;/plain (trailing or containing semicolon)

Expected Behavior

I would expect getServerSideProps and API routes to handle headers the same way. I expect the user to not be able to trigger a 500 error. I would expect either a) Next.js to return a 4xx status code, or b) Let my code handle the request as it wishes, treating any of these failing content-types the same way it currently treats the content-type of abc/def or how getServerSideProps handles it.

I would much prefer option (b).

To Reproduce

https://codesandbox.io/s/nifty-tharp-6w90w?file=/pages/api/test.js:94-100
Use Postman (or similar app) to hit the codesandbox /api/test route with a content-type: text/plain; header (note the trailing semicolon)

Any API endpoint can reproduce, for example:

export default async (req, res) => {
  res.setHeader("Content-Type", "text/plain");
  res.end("OK");
};
@jkjustjoshing jkjustjoshing added the bug Issue was opened via the bug report template. label May 3, 2021
@timneutkens
Copy link
Member

Just had a look into this. To reproduce I used:

fetch('http://localhost:3000/api/test', {headers: { 'content-type': 'text/abcdefg' }, method: 'POST', body: 'a=1'})

The error that comes out is:

TypeError: invalid parameter format
    at parse (/Users/timneutkens/projects/my-app/node_modules/next/dist/compiled/content-type/index.js:1:1479)
    at parseBody (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/api-utils.js:11:80)
    at apiResolver (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/api-utils.js:6:48)
    at DevServer.handleApiRequest (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/next-server.js:66:492)
    at async Object.fn (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/next-server.js:58:580)
    at async Router.execute (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/router.js:25:67)
    at async DevServer.run (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/next-server.js:68:1042)
    at async DevServer.handleRequest (/Users/timneutkens/projects/my-app/node_modules/next/dist/next-server/server/next-server.js:32:504)

Specifically this line:

const contentType = parse(req.headers['content-type'] || 'text/plain')
causes an error when invalid content-types are provided. getServerSideProps does not have automatic body parsing currently which is why it does not error for that case.

In this case I think you could change the behavior to be text/plain when the content type could not be parsed.

@timneutkens timneutkens added good first issue Easy to fix issues, good for newcomers and removed bug Issue was opened via the bug report template. labels May 4, 2021
@timneutkens timneutkens added this to the backlog milestone May 4, 2021
@kodiakhq kodiakhq bot closed this as completed in #24818 May 5, 2021
kodiakhq bot pushed a commit that referenced this issue May 5, 2021
Fixes #24768

## Bug

- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
flybayer pushed a commit to blitz-js/next.js that referenced this issue Jun 1, 2021
Fixes vercel#24768

## Bug

- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Easy to fix issues, good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants