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

New Feature: Add support for parsing JSON-like Content-types #15

Closed
diosney opened this issue May 10, 2014 · 10 comments
Closed

New Feature: Add support for parsing JSON-like Content-types #15

diosney opened this issue May 10, 2014 · 10 comments

Comments

@diosney
Copy link

diosney commented May 10, 2014

For instance, the ability to parse Content-types === 'xxx+json', like application/vnd.api+json, fi.

Currently bodyParser.json() only parses Content-types === 'application/json', which is very limited.

Thanks

Related: #13

@dougwilson
Copy link
Contributor

I think we can easily add this as the option to accept a string in the options object and just provide that string to type-is.

@Fishrock123
Copy link
Contributor

I'm not 100% sure how type-is works, but I think that would mean the new string would become the only correct JSON type.

Imo, the easiest and best way to fix this is just like /json/.test(req.headers['content-type']).

@dougwilson
Copy link
Contributor

That is how type-is works, but it's perfectly fine. If you want to parse both application/json and application/vnd.api+json you would just do:

app.use(bodyParser.json())
app.use(bodyParser.json({type: 'application/vnd.api+json'}))

Using a parser for each type also would let the user do stuff like giving a different reviver per type.

@Fishrock123
Copy link
Contributor

+1 didn't really know you could do that.

@diosney
Copy link
Author

diosney commented May 11, 2014

@dougwilson: Neat! I like the new way :) Thanks!

When this feature will be get published in the npm registry?

@dougwilson
Copy link
Contributor

When this feature will be get published in the npm registry?

As soon as I can, so probably today some time. I like to let the potential release sit a bit before hitting "publish" so I can think on it and prevent some dumb mistake :)

@Fishrock123
Copy link
Contributor

Also gives time for people (read: me) to land doc nits before the next release hah. :P

@dougwilson
Copy link
Contributor

@Fishrock123 I saw that commit, haha.

@dougwilson
Copy link
Contributor

@diosney published as 1.1.0

@diosney
Copy link
Author

diosney commented May 11, 2014

@dougwilson Thanks! I already tested it and worked like a charm. :)

Thanks again for your hard work :)

@expressjs expressjs locked and limited conversation to collaborators Jul 20, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants