Giter Site home page Giter Site logo

body-parser's Introduction

body-parser

NPM Version NPM Downloads Build Status Test Coverage

Node.js body parsing middleware.

Parse incoming request bodies in a middleware before your handlers, available under the req.body property.

Note As req.body's shape is based on user-controlled input, all properties and values in this object are untrusted and should be validated before trusting. For example, req.body.foo.toString() may fail in multiple ways, for example the foo property may not be there or may not be a string, and toString may not be a function and instead a string or other user input.

Learn about the anatomy of an HTTP transaction in Node.js.

This does not handle multipart bodies, due to their complex and typically large nature. For multipart bodies, you may be interested in the following modules:

This module provides the following parsers:

Other body parsers you might be interested in:

Installation

$ npm install body-parser

API

var bodyParser = require('body-parser')

The bodyParser object exposes various factories to create middlewares. All middlewares will populate the req.body property with the parsed body when the Content-Type request header matches the type option, or an empty object ({}) if there was no body to parse, the Content-Type was not matched, or an error occurred.

The various errors returned by this module are described in the errors section.

bodyParser.json([options])

Returns middleware that only parses json and only looks at requests where the Content-Type header matches the type option. This parser accepts any Unicode encoding of the body and supports automatic inflation of gzip and deflate encodings.

A new body object containing the parsed data is populated on the request object after the middleware (i.e. req.body).

Options

The json function takes an optional options object that may contain any of the following keys:

inflate

When set to true, then deflated (compressed) bodies will be inflated; when false, deflated bodies are rejected. Defaults to true.

limit

Controls the maximum request body size. If this is a number, then the value specifies the number of bytes; if it is a string, the value is passed to the bytes library for parsing. Defaults to '100kb'.

reviver

The reviver option is passed directly to JSON.parse as the second argument. You can find more information on this argument in the MDN documentation about JSON.parse.

strict

When set to true, will only accept arrays and objects; when false will accept anything JSON.parse accepts. Defaults to true.

type

The type option is used to determine what media type the middleware will parse. This option can be a string, array of strings, or a function. If not a function, type option is passed directly to the type-is library and this can be an extension name (like json), a mime type (like application/json), or a mime type with a wildcard (like */* or */json). If a function, the type option is called as fn(req) and the request is parsed if it returns a truthy value. Defaults to application/json.

verify

The verify option, if supplied, is called as verify(req, res, buf, encoding), where buf is a Buffer of the raw request body and encoding is the encoding of the request. The parsing can be aborted by throwing an error.

bodyParser.raw([options])

Returns middleware that parses all bodies as a Buffer and only looks at requests where the Content-Type header matches the type option. This parser supports automatic inflation of gzip and deflate encodings.

A new body object containing the parsed data is populated on the request object after the middleware (i.e. req.body). This will be a Buffer object of the body.

Options

The raw function takes an optional options object that may contain any of the following keys:

inflate

When set to true, then deflated (compressed) bodies will be inflated; when false, deflated bodies are rejected. Defaults to true.

limit

Controls the maximum request body size. If this is a number, then the value specifies the number of bytes; if it is a string, the value is passed to the bytes library for parsing. Defaults to '100kb'.

type

The type option is used to determine what media type the middleware will parse. This option can be a string, array of strings, or a function. If not a function, type option is passed directly to the type-is library and this can be an extension name (like bin), a mime type (like application/octet-stream), or a mime type with a wildcard (like */* or application/*). If a function, the type option is called as fn(req) and the request is parsed if it returns a truthy value. Defaults to application/octet-stream.

verify

The verify option, if supplied, is called as verify(req, res, buf, encoding), where buf is a Buffer of the raw request body and encoding is the encoding of the request. The parsing can be aborted by throwing an error.

bodyParser.text([options])

Returns middleware that parses all bodies as a string and only looks at requests where the Content-Type header matches the type option. This parser supports automatic inflation of gzip and deflate encodings.

A new body string containing the parsed data is populated on the request object after the middleware (i.e. req.body). This will be a string of the body.

Options

The text function takes an optional options object that may contain any of the following keys:

defaultCharset

Specify the default character set for the text content if the charset is not specified in the Content-Type header of the request. Defaults to utf-8.

inflate

When set to true, then deflated (compressed) bodies will be inflated; when false, deflated bodies are rejected. Defaults to true.

limit

Controls the maximum request body size. If this is a number, then the value specifies the number of bytes; if it is a string, the value is passed to the bytes library for parsing. Defaults to '100kb'.

type

The type option is used to determine what media type the middleware will parse. This option can be a string, array of strings, or a function. If not a function, type option is passed directly to the type-is library and this can be an extension name (like txt), a mime type (like text/plain), or a mime type with a wildcard (like */* or text/*). If a function, the type option is called as fn(req) and the request is parsed if it returns a truthy value. Defaults to text/plain.

verify

The verify option, if supplied, is called as verify(req, res, buf, encoding), where buf is a Buffer of the raw request body and encoding is the encoding of the request. The parsing can be aborted by throwing an error.

bodyParser.urlencoded([options])

Returns middleware that only parses urlencoded bodies and only looks at requests where the Content-Type header matches the type option. This parser accepts only UTF-8 encoding of the body and supports automatic inflation of gzip and deflate encodings.

A new body object containing the parsed data is populated on the request object after the middleware (i.e. req.body). This object will contain key-value pairs, where the value can be a string or array (when extended is false), or any type (when extended is true).

Options

The urlencoded function takes an optional options object that may contain any of the following keys:

extended

The extended option allows to choose between parsing the URL-encoded data with the querystring library (when false) or the qs library (when true). The "extended" syntax allows for rich objects and arrays to be encoded into the URL-encoded format, allowing for a JSON-like experience with URL-encoded. For more information, please see the qs library.

Defaults to true, but using the default has been deprecated. Please research into the difference between qs and querystring and choose the appropriate setting.

inflate

When set to true, then deflated (compressed) bodies will be inflated; when false, deflated bodies are rejected. Defaults to true.

limit

Controls the maximum request body size. If this is a number, then the value specifies the number of bytes; if it is a string, the value is passed to the bytes library for parsing. Defaults to '100kb'.

parameterLimit

The parameterLimit option controls the maximum number of parameters that are allowed in the URL-encoded data. If a request contains more parameters than this value, a 413 will be returned to the client. Defaults to 1000.

type

The type option is used to determine what media type the middleware will parse. This option can be a string, array of strings, or a function. If not a function, type option is passed directly to the type-is library and this can be an extension name (like urlencoded), a mime type (like application/x-www-form-urlencoded), or a mime type with a wildcard (like */x-www-form-urlencoded). If a function, the type option is called as fn(req) and the request is parsed if it returns a truthy value. Defaults to application/x-www-form-urlencoded.

verify

The verify option, if supplied, is called as verify(req, res, buf, encoding), where buf is a Buffer of the raw request body and encoding is the encoding of the request. The parsing can be aborted by throwing an error.

Errors

The middlewares provided by this module create errors using the http-errors module. The errors will typically have a status/statusCode property that contains the suggested HTTP response code, an expose property to determine if the message property should be displayed to the client, a type property to determine the type of error without matching against the message, and a body property containing the read body, if available.

The following are the common errors created, though any error can come through for various reasons.

content encoding unsupported

This error will occur when the request had a Content-Encoding header that contained an encoding but the "inflation" option was set to false. The status property is set to 415, the type property is set to 'encoding.unsupported', and the charset property will be set to the encoding that is unsupported.

entity parse failed

This error will occur when the request contained an entity that could not be parsed by the middleware. The status property is set to 400, the type property is set to 'entity.parse.failed', and the body property is set to the entity value that failed parsing.

entity verify failed

This error will occur when the request contained an entity that could not be failed verification by the defined verify option. The status property is set to 403, the type property is set to 'entity.verify.failed', and the body property is set to the entity value that failed verification.

request aborted

This error will occur when the request is aborted by the client before reading the body has finished. The received property will be set to the number of bytes received before the request was aborted and the expected property is set to the number of expected bytes. The status property is set to 400 and type property is set to 'request.aborted'.

request entity too large

This error will occur when the request body's size is larger than the "limit" option. The limit property will be set to the byte limit and the length property will be set to the request body's length. The status property is set to 413 and the type property is set to 'entity.too.large'.

request size did not match content length

This error will occur when the request's length did not match the length from the Content-Length header. This typically occurs when the request is malformed, typically when the Content-Length header was calculated based on characters instead of bytes. The status property is set to 400 and the type property is set to 'request.size.invalid'.

stream encoding should not be set

This error will occur when something called the req.setEncoding method prior to this middleware. This module operates directly on bytes only and you cannot call req.setEncoding when using this module. The status property is set to 500 and the type property is set to 'stream.encoding.set'.

stream is not readable

This error will occur when the request is no longer readable when this middleware attempts to read it. This typically means something other than a middleware from this module read the request body already and the middleware was also configured to read the same request. The status property is set to 500 and the type property is set to 'stream.not.readable'.

too many parameters

This error will occur when the content of the request exceeds the configured parameterLimit for the urlencoded parser. The status property is set to 413 and the type property is set to 'parameters.too.many'.

unsupported charset "BOGUS"

This error will occur when the request had a charset parameter in the Content-Type header, but the iconv-lite module does not support it OR the parser does not support it. The charset is contained in the message as well as in the charset property. The status property is set to 415, the type property is set to 'charset.unsupported', and the charset property is set to the charset that is unsupported.

unsupported content encoding "bogus"

This error will occur when the request had a Content-Encoding header that contained an unsupported encoding. The encoding is contained in the message as well as in the encoding property. The status property is set to 415, the type property is set to 'encoding.unsupported', and the encoding property is set to the encoding that is unsupported.

Examples

Express/Connect top-level generic

This example demonstrates adding a generic JSON and URL-encoded parser as a top-level middleware, which will parse the bodies of all incoming requests. This is the simplest setup.

var express = require('express')
var bodyParser = require('body-parser')

var app = express()

// parse application/x-www-form-urlencoded
app.use(bodyParser.urlencoded({ extended: false }))

// parse application/json
app.use(bodyParser.json())

app.use(function (req, res) {
  res.setHeader('Content-Type', 'text/plain')
  res.write('you posted:\n')
  res.end(JSON.stringify(req.body, null, 2))
})

Express route-specific

This example demonstrates adding body parsers specifically to the routes that need them. In general, this is the most recommended way to use body-parser with Express.

var express = require('express')
var bodyParser = require('body-parser')

var app = express()

// create application/json parser
var jsonParser = bodyParser.json()

// create application/x-www-form-urlencoded parser
var urlencodedParser = bodyParser.urlencoded({ extended: false })

// POST /login gets urlencoded bodies
app.post('/login', urlencodedParser, function (req, res) {
  res.send('welcome, ' + req.body.username)
})

// POST /api/users gets JSON bodies
app.post('/api/users', jsonParser, function (req, res) {
  // create user in req.body
})

Change accepted type for parsers

All the parsers accept a type option which allows you to change the Content-Type that the middleware will parse.

var express = require('express')
var bodyParser = require('body-parser')

var app = express()

// parse various different custom JSON types as JSON
app.use(bodyParser.json({ type: 'application/*+json' }))

// parse some custom thing into a Buffer
app.use(bodyParser.raw({ type: 'application/vnd.custom-type' }))

// parse an HTML body into a string
app.use(bodyParser.text({ type: 'text/html' }))

License

MIT

body-parser's People

Contributors

azhao12345 avatar beeman avatar cha147 avatar commanderroot avatar djchie avatar dougwilson avatar fishrock123 avatar govindrai avatar hopefulllama avatar jdspugh avatar jonathanong avatar lazywithclass avatar ljharb avatar mscdex avatar msemtd avatar sehrope avatar shawninder avatar thethp avatar timokasse avatar tlhunter avatar tomk32 avatar yanxyz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

body-parser's Issues

Better error logging

SyntaxError: Unexpected token $
  at Object.parse (native)
  at parse (/etc/acme/webauth/node_modules/body-parser/lib/types/json.js:84:17)
  at /etc/acme/webauth/node_modules/body-parser/lib/read.js:102:18
  at IncomingMessage.onEnd (/etc/acme/webauth/node_modules/body-parser/node_modules/raw-body/index.js:136:7)
  at IncomingMessage.g (events.js:180:16)
  at IncomingMessage.emit (events.js:92:17)
  at _stream_readable.js:944:16
  at process._tickDomainCallback (node.js:486:13)

This doesn't help much in debugging the request. Is there a way to catch this and log a simple warning message?

Cannot call method 'getFileName' of undefined

Hi i'm using v1.3.0 & occasionally get following error :

TypeError: Cannot call method 'getFileName' of undefined
at callSiteLocation (/mnt/applane/dev/node_modules/body-parser/node_modules/depd/index.js:221:23)
at Function.log (/mnt/applane/dev/node_modules/body-parser/node_modules/depd/index.js:166:12)
at deprecate (/mnt/applane/dev/node_modules/body-parser/node_modules/depd/index.js:103:9)
at Function.urlencoded (/mnt/applane/dev/node_modules/body-parser/lib/types/urlencoded.js:41:5)
at bodyParser (/mnt/applane/dev/node_modules/body-parser/index.js:74:29)
at eval (eval at wrapfunction (/mnt/applane/dev/node_modules/body-parser/node_modules/depd/index.js:344:5), :3:11)
at Layer.handle (/mnt/applane/dev/node_modules/ApplaneDB/lib/Http.js:391:13)
at trim_prefix (/mnt/applane/dev/node_modules/express/lib/router/index.js:254:17)
at /mnt/applane/dev/node_modules/express/lib/router/index.js:216:9
at Function.proto.process_params (/mnt/applane/dev/node_modules/express/lib/router/index.js:286:12)

Custom error in case of malformed JSON

In case of marformed json, body-parser passes generic SyntaxError. I perform error processing in the end of middleware chain, while app.use(bodyParser.json()); is at the beginning. Other middlewares can potentially throw SyntaxError too. Currently I can not distinguish SyntaxError which comes from body-parser (I wish to respond with 400 Bad Request) and other SyntaxErrors (I respond with 500 Server Error), so I workaround it intercepting and wrapping SyntaxError just after body-parser, like this:

// Parse JSON requests using body-parser
app.use(bodyParser.json());

// Intercept SyntaxError from body-parser
app.use(function(err, req, res, next) {
  if (err && err.name == 'SyntaxError') {
    // Wrap error
    next(new VError(err, 'Malformed JSON'));
  } else {
    next(err);
  }
});

...other middlewares...

// Handle errors
app.use(function(err, req, res, next) {
  if (err) switch (err.name) {
    case 'VError':
      err = err.cause();
      switch (err.name) {
        case 'ValidationError':
        case 'SyntaxError':
          logger.debug(err.stack);
          res.json(400, err.errors); // Bad request
          break;
      }
      break;
    default:
      logger.error(err.stack);
      res.send(500);
      return;
  }
});

Is it possible to add custom error for this scenario? Or maybe I misunderstood something?
Thank you in advance for help!

Missing body behavior for DELETE method

I believe that bodyParser should not respond with a 400 due to a missing body on a DELETE request.

In a web app I am working on, we do not provide a body in our DELETE rest requests, as all information for the delete is included in the URI. Therefore, Chrome does not send a Content-Length header for ajax delete requests. This causes the bodyParser middleware to respond with a 400 error due to the body buffer having zero length.

While I agree that is necessary for PUT and POST requests, DELETE does not specifically define semantics for the message body. Therefore it should permit a missing body for such requests. According to the spec,

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

A simple solution for DELETE requests that are missing a content-length header would be to simply set req.body = {};.

I realize that many server packages support sending a body for DELETE requests, and this would still support that.

Are there any thoughts on this topic, or any considerations I am overlooking that would make implementing this a bad thing?

Json Verify Option

In express 3.5 we used to have a json verify option. It was quite nice feature to use to get the fully buffered raw body when dealing with facebook X-Hub Signed Requests.
Could we please get this back in? Thanks.

Currently mandatory use of "Content-Type": "application/json" header

In the past, this module used to parse json data no matter the Content-Type header was set or not, but since the inclusion of the type-is module, it has changed and now even if the data sent from the client is in json format, it won't parse it unless the Content-Type header is set to application/json.

Is this the way to use this module from now on or is this something intended to be changed in the future?

Cheers!

Passing a boolean value

Hello,

I've been trying to pass a bool value to Node.js but I couldn't.
My json object like { archive: false } before an ajax process. I can get as { "archive": "false" }. I want to use as a bool value in my database.

Is it possible? Can I get as a bool value?

Bug with form arrays and bodyParser

senchalabs/connect#1025 -- I put this error there first, but was directed here.

I just found a wierd bug when using bodyParser and form arrays.

I have a form elements with names of
items[1]
items[2]
etc.

When these submit, I get an array from bodyParser that looks like:
{ items: ['on', 'on'] }

rather than:
{ items: { 1: 'on', 2: 'on' } }

If instead I change the form to have names of
items[id_1]
items[id_2]

it works great (except now I need to replace id_)

dougwilson over on the other form brings up a good point against treating it like an array, but honestly just dropping the values on the floor is worse than the possible problem. Making it always an object if the id's are specified seems like the only answer. That way it works the same as PHP does, which makes a lot of sense.

Allow options to be passed to the qs module when using bodyParser.urlencoded({ extended: true })

I have run into an issue with urlencoded sparse arrays and the way the qs module is handling them:

When creating arrays with specific indices, qs will compact a sparse array to only the existing values preserving their order.

Qs.parse('a[1]=b&a[15]=c');
// { a: ['b', 'c'] }

Ideally I would like to be able to pass options to the qs.parse() call so that I can override the arrayLimit option. I believe the syntax for doing this could look something like this:

bodyParser.urlencoded({
  extended: {
    arrayLimit: 0
  }
})

The extended option would still evaluate to "truthy" and would therefore use the qs module for parsing, but it would also allow developers to override the current hardset arrayLimit option passed to qs.parse() (along with any other qs specific options).

Having problems since an update.

I had this working before but now have updated to newer body parser in which I have tried both

  app.use(bodyParser.urlencoded({
    extended: false
  }));

and

  app.use(bodyParser.urlencoded({
    extended: true
  }));

with no success.

I've got the following form posting

<form action='/testform' method="post">
  <input type="text" name="first_name" value="John">
  <input type="text" name="last_name" value="Doe">
  <input type="text" name="food[name]" value="Lasagna">
  <input type="text" name="food[type]" value="Dinner">
  <input type="text" name="food[origin]" value="Italy">
  <input type="text" name="order[0][quantity]" value="5">
  <input type="text" name="order[0][size]" value="small">
  <input type="text" name="order[0][status]" value="frozen">
  <input type="text" name="order[1][quantity]" value="2">
  <input type="text" name="order[1][size]" value="large">
  <input type="text" name="order[1][status]" value="cooked">
  <input type="hidden" name="_csrf" value="<%- token %>">
  <input name="submit" type="submit" value="submit"/>
</form>

with extended:false, looking at req.body I get:

{ first_name: 'John',
  last_name: 'Doe',
  'food[name]': 'Lasagna',
  'food[type]': 'Dinner',
  'food[origin]': 'Italy',
  'order[0][quantity]': '5',
  'order[0][size]': 'small',
  'order[0][status]': 'frozen',
  'order[1][quantity]': '2',
  'order[1][size]': 'large',
  'order[1][status]': 'cooked',
  _csrf: 'rXgHoLAH-yZJ34JdmcM9Ry2bHCwraxcovMtg',
  submit: 'submit' }

or with extended: true

{ first_name: 'John',
  last_name: 'Doe',
  food: { name: 'Lasagna', type: 'Dinner', origin: 'Italy' },
  order: [ { status: 'frozen' }, { status: 'cooked' } ],
  _csrf: 'rXgHoLAH-yZJ34JdmcM9Ry2bHCwraxcovMtg',
  submit: 'submit' }

What I expect:

{ first_name: 'John',
  last_name: 'Doe',
  food: { name: 'Lasagna', type: 'Dinner', origin: 'Italy' },
  order: [ { quantity: 5, size:'small', status: 'frozen' }, { quantity: 2, size: 'large', status: 'cooked' } ],
  _csrf: 'rXgHoLAH-yZJ34JdmcM9Ry2bHCwraxcovMtg',
  submit: 'submit' }

Add multipart/form-data support

This is just such a basic type of the web, it's hard to keep ignoring it. Because of the pattern of this module, though, we really cannot support files. But I don't see why we can support it, but just drop files. Thoughts?

req.files

This is more of a question than an issue, but where is the file handling middleware in Express 4?

Should be able to not use qs for urlencoded parsing

It's too bad using qs is the default, but at least we should provide an option to use something else like querystring that can parse flat to reduce the attack surface of applications. This would let users parse with urlencoded and not have to handle complex values.

Problem when content-length is not set.

Hi,

This issue seem that belong to the "raw-body" package that "body-parser" uses.

I found a problem that when the content-length header field is not set (in case that i'm using ajax with http verb DELETE by browser doesn't send content-length), and data length is smaller than the limit bytes, the "end" event is never fired so my callback handler is never called. Is there any way for solving this issue, such as setting a timeout?

Thanks.

build-your-own-parser

If you look at the middleware, after I had refactored it, all they are is a call to typeis and a call to read. We should add something like bodyParser.generic() to let people roll their owner simple body parsers.

Should assert content-type charset

Right now this module does not care what the charset is set to in the request, just blindly assuming it is utf-8. This works fine in general, until someone sends non-utf8 data (mainly to urlencoded) and garbage comes out. I'm not suggesting we support all the charsets and codepages, but at least make it an error to specify a charset we know we don't support.

Error: unsupported charset "UTF8"

Hi

After I upgrade body-parser module from 1.3.x to last version (1.9) this message error occurred

Error: unsupported charset "UTF8"
    at urlencodedParser (/mypath/node_modules/body-parser/lib/types/urlencoded.js:76:17)
    at Layer.handle [as handle_request] (/mypath/node_modules/express/lib/router/layer.js:76:5)
    at trim_prefix (/mypath/node_modules/express/lib/router/index.js:270:13)
    at /mypath/node_modules/express/lib/router/index.js:237:9
    at Function.proto.process_params (/mypath/node_modules/express/lib/router/index.js:312:12)
    at /mypath/node_modules/express/lib/router/index.js:228:12
    at Function.match_layer (/mypath/node_modules/express/lib/router/index.js:295:3)
    at next (/mypath/node_modules/express/lib/router/index.js:189:10)
    at expressInit (/mypath/node_modules/express/lib/middleware/init.js:23:5)
    at Layer.handle [as handle_request] (/mypath/node_modules/express/lib/router/layer.js:76:5)

working together

@dougwilson @jonathanong @andrewrk Hey guys- I hadn't noticed this repo until very recently. We're using Skipper (which currently uses multiparty) in the Sails beta (which is currently on Express 3- we've been waiting to upgrade until after we get everything else out to reduce the number of variables).

Anyways I'm very interested in combining our efforts, whether that's depending on this module, or pulling out shared dependencies, before we upgrade to E4, or after, etc. Would you be down to chat about it this weekend or next week some time?

qs' depth

Hi there,

I'm using express + body-parser in my app and I ran into some very odd issue with deeper keys in a nested object coming out with brackets surrounding the keys, took me a while to figure out what was causing it.

Apparently qs accepts a depth option in order to go deeper... is there any support planned for this, or should I write my own qs parser in that case?

Cheers

Deprecated middleware

Since today after having done npm update, using

"body-parser": "^1.3.0",
"express": "^4.4.1",

I get the following warning message at the console

body-parser deprecated bodyParser: use individual json/urlencoded middlewares
urlencoded: explicitly specify "extended: true" for extended parsing

How do I get rid of these ?

Thank you.

Add smarter handling for jQuery arrays

jQuery does two things somewhat oddly regarding arrays, it would be really helpful if the body parser took these into account.

First, in modern versions of jQuery (>= 1.5), arrays that are included in AJAX data are passed with square brackets appended to their name. This can be overridden by adding the traditional: true parameter on the client side. Even with that parameter, a single array parameter is interpreted as a string.

Ideally, body parser should have tests specifically to cover jQuery's use of arrays, and should treat any parameter whose name has trailing square brackets as an array regardless of the number of elements.

Parsing complex json structure

How to parse this:

{
    "schemas":["urn:scim:schemas:core:1.0"],
    "userName":"bjensen",
    "name":{
        "formatted":"Ms. Barbara J Jensen III",
        "familyName":"Jensen",
        "givenName":"Barbara"
    },
    "emails":[{
        "type":"home",
        "value":"[email protected]"
    }],
}

Here's what I'm working with:

var jsonParser = bodyParser.json({ type: 'application/*+json' } );
router.post('/create-account', jsonParser, function(req, res) { 
  console.log(req.body)
});

"RangeError: Maximum call stack size exceeded" (urlencode) / "SyntaxError: Unexpected token" (json)

Hello.
I have this code:

var express = require("express")
var bp = require("body-parser")
var app = express()
var bpurle= app.use(bp.urlencoded({ extended: false }))
var bpjson= app.use(bp.json())
app.post("/urle", bpurle, function(req, res) {
    if (req.body === undefined) {return(console.log("There aren't any data"))}
    console.log("Received data via URL-Encode:\n" + req.body)
})
app.post("/json", bpjson, function(req, res) {
    if (req.body === undefined) {return(console.log("There aren't any data"))}
    console.log("Received data via JSON:\n" + JSON.stringify(req.body,null,2))
})
app.listen(4000)

When I execute...

curl -X POST http://127.0.0.1:4000/urle -d "data1=value1&data2=1234"

...I get this error:

RangeError: Maximum call stack size exceeded
    at next (/home/q2dg/node_modules/express/lib/router/index.js:168:16)
    at next (/home/q2dg/node_modules/express/lib/router/route.js:100:14)
    at Layer.handle_error (/home/q2dg/node_modules/express/lib/router/layer.js:54:12)
    at next (/home/q2dg/node_modules/express/lib/router/route.js:108:13)
    at /home/q2dg/node_modules/express/lib/router/index.js:603:15
    at next (/home/q2dg/node_modules/express/lib/router/index.js:246:14)
    at next (/home/q2dg/node_modules/express/lib/router/route.js:100:14)
    at Layer.handle_error (/home/q2dg/node_modules/express/lib/router/layer.js:54:12)
    at next (/home/q2dg/node_modules/express/lib/router/route.js:108:13)
    at /home/q2dg/node_modules/express/lib/router/index.js:603:15

When I execute...

curl -X POST http://127.0.0.1:4000/json -d "{'data1':'value1','data2':'1234'}" -H "Content-Type:application/json"

...I get this error:

SyntaxError: Unexpected token '
    at Object.parse (native)
    at parse (/home/q2dg/node_modules/body-parser/lib/types/json.js:76:17)
    at /home/q2dg/node_modules/body-parser/lib/read.js:98:18
    at IncomingMessage.onEnd (/home/q2dg/node_modules/body-parser/node_modules/raw-body/index.js:136:7)
    at IncomingMessage.g (events.js:199:16)
    at IncomingMessage.emit (events.js:104:17)
    at _stream_readable.js:907:16
    at process._tickCallback (node.js:372:11)

Thanks!

Exposing middleware logic as API

Have you ever thought of exposing the body-parser middlewares as APIs that can be invoked programmatically, not as middleware, like qs does? With qs, I can do something like req.query = qs.parse(parseurl(req).query, {}); and I'd love to be able to do the same with body-parser. If not, not big deal as I can create some async chain that will call the two body-parsers in order and then call my middleware logic function. I just figured I'd ask, might even submit the PR if you're open to the idea.

req.query.param_name returns undefined.

I am currently running an Express 4.x project with the app using the body-parser module app.use(bodyParser());

Whenever I am trying to access the query parameters vs req.query.param (e.g. req.query.offset) a value of undefined is returned. However when I run req.query() the expected query string is returned offset=0

Is there something I am not adding to my application or am I using req.query incorrectly?

"express route-specific" example is not working

The "express route-specific" example is not working, specifically req.body always contains a value so this condition is always false:

 if (!req.body) return res.sendStatus(400)

And this is because of this:

  return function jsonParser(req, res, next) {
    if (req._body) return next()
    req.body = req.body || {} // <- A value is set to a blank object even if typeis fails

    if (!typeis(req, type)) return next()

Which is here:

req.body = req.body || {}

So two questions that I have is:

  • If the user does not set a Content-Type header at all, how do I default to application/json so I always get a populated object instead of an empty one? Or at the very least how do I tell them they are missing that Content-Type header?
  • If the Content-Type is set, how do I determine that it is not correct and send them an appropriate error?

urlencoded parser

I see that you have arrayLimit set to 100 which you pass onto qs module when the extended parser is being used, but this is not configurable by the end user, neither parameterLimit effects this. Can you expose this? This seems pretty trivial to me.

Parse DELETE body

Hello,

body-parser doesn't seem to parse the body for DELETE HTTP request. I need it for my project, is there a way to do it?

Vincent.

Problems with numeric nested form element names

Heys guys!

I have a form that looks more or less like this:

<input type="checkbox" name="checklist[1]" value="1" />
<input type="checkbox" name="checklist[2]" value="1" />
<input type="checkbox" name="checklist[3]" value="1" />

I was expecting that request.body.checklist looked like this (after all checkboxes were checked, of course):

{
'1': '1',
'2': '1',
'3': '1'
}

But what I got was a array, without the indexes I need to associate the result:

['1', '1', '1']

This seems like a bug to me. I would expect the array only for zero-based indexes.

Crash, if first character is "{" but json is still invalid

Hi,

I came up with an error, where client tried to post "javascript", not JSON to the express server.

e.g. body was

{ key: "value" }

This caused express app probably crashed and sent error code 0 back to client.

This affects only json body parser

Always export raw body buffer.

Instead of adding raw as a parser type, why not just always export the pre-parsed buffer as req.rawBody?

This way, if required, we can easily forward the unadulterated body buffer to upstream proxies and services, without the content-type conditionals required by the raw type.

Ensure bodyParser.urlencoded doesn't transform request body to json

From #39
How can I ensure the raw request body is what is sent? Here's what I'm toying with:

var bodyParser = require('body-parser');

router.use(function(req, res, next) {
    var data = '';
    req.on('data', function(chunk) {
            data += chunk;
        }); 
    req.on('end', function() {
            req.rawBody = data;
            next();
        }); 
});
// retrieve all request body objects
router.use(cookieParser());
router.use(bodyParser());
router.use(methodOverride());

router.post('/login', function(req, res) {
  console.log(req.rawBody);
  if (!req.body) return res.sendStatus(400);

  var options = httpconn.httpOptions({
    resource: 'uaa',
    resourcePath: '/uaa/login.do',
    method: 'POST',
    headers: {'Referer': httpconn.buildUri('uaa') + '/uaa/login'}
  });
  var httpRequest = application.httprequest(options, function(response) {
      if(response.statusCode == 302) {
        res.send(response.headers);
      } 
  });
  httpRequest.write(qs.stringify(req.rawBody));
  httpRequest.end();

To use the req.rawBody middleware, I needed to use -H 'Content-Type: text/plain'.

I want to ensure that a request with application/x-www-form-urlencoded maintains the request body as username=myname&password=mypass without transforming to {'username':'myname','password':'mypass'}

Req.Body Truncated in Versions >= 1.6.0

Upon updating my project dependencies I realized that url encoded data originating from my client app seemed to be getting severely truncated. Installing previous tags back to 1.5.x seemed to remedy the problem.. 2 quick screenshots illustrate these issues:

installed tag 1.5.2
bp-1 5 2

installed tag 1.6.0
bp-1 6 0

Big difference!
Haven't pinned down the change that's responsible for this error, but I thought you should know about this. I'm sticking with the 1.5's for the time being.
Thanks.

Multipart form data without any error!!!

Hello everybody,

i am thinking that should be nice to have an error when i am using bodyparser with unsupported multipart form data request.

I spent a lot of my time to understand it!!!

thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.