Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

koapi-body

ntfs3232MIT2.0.8

Full-featured [koa][] body parser! Support parsing text, buffer, json, json patch, json api, csp-report, multipart, form and urlencoded bodies. Works for koa@1, koa@2 and will work for koa@3.

api, awesome, better, body, body-parser, buffer, csp, csp-report, error, error-handling, extendable, feature, features, flexible, form, forms, full, full-feature, handling, json, json-api, json-patch, json-strict, jsonstrict, koa, koa-better-body, multipart, parse, parser, patch, report, rfc, standard, strict, text, unopinionated, urlencoded

readme

koa-better-body npmjs.com The MIT License npm downloads

Full-featured koa body parser! Support parsing text, buffer, json, json patch, json api, csp-report, multipart, form and urlencoded bodies. Works for koa@1, koa@2 and will work for koa@3.

code climate standard code style travis build status coverage status dependency status

You might also be interested in our recipes - working examples, answers, tips & tricks. Contribute a recipe?

Install

npm i koa-better-body --save

Features

Usage

For more use-cases see the tests

const koaBetterBody = require('koa-better-body')

koaBetterBody

Robust body parser for koa@1, also works for koa@2 (with deprecations). Will also work for future koa@3 with koa-convert.

Params

  • options {Object}: see more on options section
  • returns {GeneratorFunction}

Example

var koa = require('koa')
var body = require('koa-better-body')
var app = koa()

app
  .use(body())
  .use(function * () {
    console.log(this.body)
  })
  .listen(8080, function () {
    console.log('koa server start listening on port 8080')
  })

Options

Sane defaults. :sparkles:

Accepts JSON, JSON API v1, text, buffer, csp-report, multipart and urlencoded/form bodies. If you want to disallow accepting and parsing multipart body you should pass multipart: false. Most of the defaults you can see at utils.defaultOptions and utils.defaultTypes. All options are also been passed to formidable.IncomingForm! Even you can pass IncomingForm instance to be able to handle the different formidable events.

  • fields {Boolean|String}: Default false, which means it will set fields on this.request.fields and directly on this.body. If you pass a string, for example 'foo', you will have fields on this.body and on this.request.foo.
  • files {Boolean|String}: Default false, which means it will set files on this.request.files and this.body.files, if you pass a string, for example 'bar', it will set files on this.request.bar and this.body.bar.
  • multipart {Boolean}: Default true. If you pass false it won't accept/parse multipart bodies.
  • textLimit {String}: Default '100kb'. Passed to bytes.parse method.
  • formLimit {String}: Default '100kb'. Passed to bytes.parse method.
  • jsonLimit {String}: Default '100kb'. Passed to bytes.parse method.
  • bufferLimit {String}: Default '1mb'. Passed to bytes.parse method.
  • jsonStrict {Boolean}: Default true. When set to true, JSON parser will only accept arrays and objects.
  • detectJSON {Function}: Custom JSON request detect function - detectJSON(ctx).
  • strict {Boolean}: Default true. Pass false if you want to allow parsing GET, DELETE and HEAD requests.
  • onerror {Function}: Custom error handle, if throw an error, you can customize the response - onerror(err, ctx).
  • extendTypes {Object}: Default accepting types can find on utils.defaultTypes function. Allowing you to extend what your app can accept. By default works for JSON, JSON API v1, multipart, text, urlencoded and csp-report.
  • IncomingForm {IncomingForm}: Pass an instance of formidable.IncomingForm to be able to handle formidable events.

A note about strict mode

We are trying to follow standards. :cat2:

You can pass strict:false, but see IETF HTTP/1.1 Message Semantics: Section 6.1 to understand why we stay to "strict mode" by default. GET, HEAD, and DELETE requests have no defined semantics for the request body, but this doesn't mean they may not be valid in certain use cases. Last two tests at test/options.js are showing usage on non-strict and strict mode.

You might also be interested in these packages:

Contributing

Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
But before doing anything, please read the CONTRIBUTING.md guidelines.

Contributing Recipes

Recipes are just different use cases, written in form of README in human language. Showing some "Pro Tips" and tricks, answering common questions and so on. They look like tests, but in more readable and understandable way for humans - mostly for beginners that not reads or understand enough the README or API and tests.

  • They are in form of folders in the root recipes/ folder: for example recipes/[short-meaningful-recipe-name]/.
  • In recipe folder should exist README.md file: see recipes/multipart/README.md.
  • The examples from the recipe README.md should also exist as separate .js files.
  • Examples in recipe folder also should be working and actual.

It would be great if you follow these steps when you want to fix, update or create a recipes. :sunglasses:

  • Title for recipe idea should start with [recipe]: for example[recipe] my awesome recipe
  • Title for new recipe (PR) should also start with [recipe].
  • Titles of Pull Requests or Issues for fixing/updating some existing recipes should start with [recipe-fix].

It will help a lot, thanks in advance! :yum:

Charlike Make Reagent new message to charlike freenode #charlike

tunnckoCore.tk keybase tunnckoCore tunnckoCore npm tunnckoCore twitter tunnckoCore github

changelog

2.0.1 - 2016-05-05

  • Release v2.0.1 / npm@v2.0.1
  • fix typo
  • switch to use mukla for testing, instead of assertit - it is drop in replacement
  • add downloads badge
  • bump deps (lazy-cache to v2)

2.0.0 - 2016-04-15

  • Release v2.0.0 / npm@v2.0.0
  • in general, much things was changed and was added new and wanted features - review the v2 PR
  • closed all of the issues marked as todo and v2 (the v2 milestone)
  • in short:
    • cleared all issues marked as todo and v2
    • still using formidable
    • still can pass custom property names for fields and files - e.g. pass options.files: 'foobar'
      • defaults to this.request.fields and this.request.files
      • almost always this.body is equal to this.request.fields (when it make sense)
      • this.request.files not exist always
    • more flexible
      • can pass formidable.IncomingForm instance through options to handle events and etc
      • all options are directly passed to formidable.IncomingForm
    • change options.multipart to be true be default - pass false if you want to disallow it
    • add support for text bodies
    • add options.buffer to get the body as buffer (when text type), defaults to false
    • add options.strict mode to disallow GET, HEAD, DELETE requests, defaults to true
    • add options.jsonStrict JSON parser will only accept arrays and objects, defaults to true
    • add options.detectJSON #16 - same as in [koa-bodyparser]
    • simplified tests
    • simplify a lot of the codebase using koa-body-parsers under the hood

1.0.17 - 2015-02-06

  • Release v1.0.17 / npm@v1.0.17
  • fix license range
  • run update readme
  • update keywords
  • bump deps, actually ranges to ~ only which means only latest patch version

1.0.16 - 2015-01-19

1.0.15 - 2015-01-19

  • Release v1.0.15 / npm@v1.0.15
  • add encode alias for encoding option

1.0.14 - 2015-01-18

  • Release v1.0.14 / npm@v1.0.14
  • istanbul ignore
  • coverage tweaks
  • increase max statements to 20
  • closes #10, update/add tests

1.0.13 - 2015-01-17

  • Release v1.0.13 / npm@v1.0.13
  • update dotfiles and jscs rules
  • revert back filesKey option

1.0.12 - 2014-11-27

  • Release v1.0.12 / npm@v1.0.12
  • bump to jscs >= 1.8.0 and jscs-doc >= 0.2.0
  • update semver range

1.0.11 - 2014-11-27

  • Release v1.0.11 / npm@v1.0.11
  • fix code style collisions

1.0.10 - 2014-11-27

  • Release v1.0.10 / npm@v1.0.10
  • docs, readme, coveralls
  • edit safeContext in .jscsrc

1.0.9 - 2014-11-27

  • Release v1.0.9 / npm@v1.0.9
  • bump jscs-jsdoc to v0.1.0
  • update jscs config .jscsrc

1.0.8 - 2014-11-26

  • Release v1.0.8 / npm@v1.0.8
  • normalize (dot)files
  • update all to apply jshint/jscs code style
    • add .jscsrc and .jshintignore
  • update makefile and scripts in package.json

1.0.7 - 2014-10-26

  • Release v1.0.7 / npm@v1.0.7
  • update names of some tests (rfc7231) "Request Entity Too Large" -> "Payload Too Large"
  • add doc blocks

1.0.6 - 2014-10-25

  • Release v1.0.6 / npm@v1.0.6
  • update automation
  • improve code coverage
  • add Makefile
  • add npm run scripts

1.0.5 - 2014-10-25

1.0.4 - 2014-10-21

1.0.3 - 2014-07-03

  • Release v1.0.3 / npm@v1.0.3
  • Pretty styling
  • auto badges
  • add history
  • add [extend][extend-url], because of options merging bug.
  • add better tests - only 7, for all use cases.
  • need suggestions for error 413 handling, maybe [raw-body][rawbody-url] problem/logic?
  • when upload, always returned type is application/octet-stream, not image/png, image/gif, etc - maybe [formidable][formidable-url] problem/logic?
  • deprecation message also comes from formidable
  • always json and urlencoded bodies will be pushed to request .body.fields object. (fixed in v1.0.4)

1.0.0 - 2014-06-08

0.0.0 - 2014-06-08

  • Initial commits