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

Added support for external parsers to bodyParser.json() #281

Closed
wants to merge 7 commits into from

Conversation

sdellysse
Copy link

@sdellysse sdellysse commented Nov 21, 2017

Added the option to use a function other than JSON.parse to do the actual parsing. This fixes #278; contrary to one of the suggestions in that issue I left the reviver option as-is for backward compatibility. Also see #42, where adding a similar option for query string parsing was the preferred choice.

Copy link
Contributor

@dougwilson dougwilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that ultimately that issue should be resolved by implementing to a long standing issuehttps://github.com//issues/22 instead of this hakf way one. Or at the very least add a parser option to every parser type because I'm sure the same argument for needig custom applies across the board.

}
}

try {
debug('parse json')
return JSON.parse(body, reviver)
return parser(body, reviver)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is right for custom parsers. Or at least it's not clear in the docs for the parser option that this is going to happen and how people should build their parser dunxtion to compensate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other option would be to remove the reviver param and rely on people using that parameter should change to this. I didn't do that as that would break BC, and I figure a project like this wouldn't want to break BC very often.

Maybe the right way is to make the docs more clear about this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I commented on the wrog line.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I don't think I can agree with you that the docs are not clear:

The reviver option is passed directly to the parser as the second argument.

If you can suggest an update to that text I'm all ears.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved my comment down. The new comment for this line is to clarify in the docs the arguments the custom parser will be called with.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the line from the reviver docs and add in the specific signature into the parser docs. The current parser section doesn't help someone build their own, I think it assumes someone is going to understand JSON.parse and copy that? If so, just write that down.

var index = str.indexOf(char)
var partial = str.substring(0, index) + '#'

try {
JSON.parse(partial); /* istanbul ignore next */ throw new SyntaxError('strict violation')
parser(partial); /* istanbul ignore next */ throw new SyntaxError('strict violation')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the line my above comment was supposed to be on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is right for custom parsers. Or at least it's not clear in the docs for the parser option that this is going to happen and how people should build their parser function to compensate.

var index = str.indexOf(char)
var partial = str.substring(0, index) + '#'

try {
JSON.parse(partial); /* istanbul ignore next */ throw new SyntaxError('strict violation')
parser(partial); /* istanbul ignore next */ throw new SyntaxError('strict violation')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is right for custom parsers. Or at least it's not clear in the docs for the parser option that this is going to happen and how people should build their parser function to compensate.

}
}

try {
debug('parse json')
return JSON.parse(body, reviver)
return parser(body, reviver)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved my comment down. The new comment for this line is to clarify in the docs the arguments the custom parser will be called with.

@dougwilson
Copy link
Contributor

Ok, just wanted to give feedback real quick. I'll be gone for tge holiday and back next week, so see how far you can get on the changes by then or let me know asap if you have comments on the overall request I made instead of just those line comments.

@sdellysse
Copy link
Author

Ah, I see what you're saying now. I'll work on the rest, hope you have a good holiday!

@dougwilson
Copy link
Contributor

I love the changes! I'm not sure if you responded to my general comment, maybe I missed it. Why not implement #22 to resolve the underlying issue? I'm just curious because that's still needed and if course that eould replace this causing more API churn in the log run.

Copy link
Contributor

@dougwilson dougwilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general great!

@@ -86,16 +86,27 @@ specifies the number of bytes; if it is a string, the value is passed to the
[bytes](https://www.npmjs.com/package/bytes) library for parsing. Defaults
to `'100kb'`.

##### parser

The `parser` option is the function called against the request body to convert
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No description of the first argument. Also doesn't describe the mechanism of how it needs to be made to construct the syntax error during the recalling mechanism with the # inserted into the original string.

@@ -49,7 +50,7 @@ function raw (options) {
: type

function parse (buf) {
return buf
return parser(buf)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't need two levels of functions here. Just replace parse with a variable.

@@ -51,7 +52,7 @@ function text (options) {
: type

function parse (buf) {
return buf
return parser(buf)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't need two levels of functions here. Just replace parse with a variable.

@@ -159,6 +170,15 @@ 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.

##### parser

The `parser` option, if supplied, is used to transform the body of a request
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably describe the type and number of arguments it will be called with.

@@ -208,6 +228,15 @@ 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.

##### parser

The `parser` option, if supplied, is used to transform the body of a request
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably describe the type and number of arguments it will be called with.

@@ -274,6 +303,16 @@ 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.

##### parser

The `parser` option, if supplied, is used to in place of the default parser to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably mention the type of the argument and also that it is not called at all for zero length bodies (though, should it be always called because what if they want a zero length result to be something other than {}?). The other parsers seem to be called on zero length, so this seems odd not to.


The `parser` option, if supplied, is used to in place of the default parser to
convert the request body into a Javascript object. If this option is supplied,
both the `extended` and `parameterLimit` options are ignored.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the json parser, the reviver is not ignore but these are. Should json work like this and ignore the arguments that were originally going to the underlying parser that is now replaced, or should these be passed to the new urlencoded parser somehow or neither and a warning is a user gave these? Some thoughts.

@sdellysse
Copy link
Author

Closing, superceded by PR #282

@sdellysse sdellysse closed this Nov 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Any plans to support larger than 53-bit integers?
2 participants