Closed Cinnamals closed 4 weeks ago
--data '{"read": falsre}'
The value falsre
is not valid JSON. JSON requires that strings be enclosed in double quotes. Since falsre
is not enclosed in quotes, the parser assumes it's a boolean or other primitive type, but because falsre
isn't recognized as a valid keyword (like true
or false
), the parser throws an error.
--data '{"read": "falsre"}'
Here, "falsre"
is properly treated as a string, making the JSON valid.
So, in this case, the error is correct because the value "falsre"
needs to be wrapped in double quotes for it to be recognized as a string.
So, in this case, the error is correct because the value "falsre" needs to be wrapped in double quotes for it to be recognized as a string.
I don't think the question is whether or not the "error is correct" - it's certainly a valid error - but whether or not the behavior should be automatically returning HTML in the response.
Is this the expected behaviour?
It looks like it is. If you look at the code snippet below, you see that it tries to parse the body on line 131. When that fails, the error is caught and a 400-status error response is created and passed as the callback (effectively replacing yours, it seems like).
So, what it looks like to me is that your comment "// An HTML body is returned here when misspelling a boolean value."
is not quite accurate. I don't think your callback is ever actually invoked. Indeed, I wouldn't expect your console log "I'm in"
to be called in this scenario. The error is caught and handled while processing through the middleware, before it gets to your callback.
Looks like the middleware is annotating the req
object before it gets passed to your callback. This makes the current behavior make some sense, because if it can't parse the body, how should it communicate that through the req
and res
objects it passes to you? So I think that's why you're seeing a default response.
That said, it would be nice to have control over how your service responds (pun intended!) to bad user input. I'm not sure if or how express
allows for any customization of that behavior.
Turns out, this is indeed documented behavior.
@Cinnamals The way to resolve this and gain control over the error handling is to write custom error handling middleware. See the Writing Error Handlers
section. If you define it after the JSON handling middleware, the error response will be given to your middleware:
app.use(express.json());
app.use((err, req, res, next) => {
console.error(err.message); // You will get the error from the body-parser here
res.status(500).send('Something broke!');
})
@Cinnamals The way to resolve this and gain control over the error handling is to write custom error handling middleware. See the
Writing Error Handlers
section. If you define it after the JSON handling middleware, the error response will be given to your middleware:app.use(express.json()); app.use((err, req, res, next) => { console.error(err.message); // You will get the error from the body-parser here res.status(500).send('Something broke!'); })
Yes, thank you. I stupidly edited out that I am aware of this.
And I should have clarified that I am curious about sending primitive data types, not wrapping the value in quotation marks as to handle it as a string, like the first reply from @gulbaki suggests.
I am happy with your first replies, @dpopp07 ! I shouldve been faster to thank you. :)
Thanks for all the replies.
No worries! Glad it was helpful
@UlisesGascon I think this can be closed
Hi! I have a question about the way the body-parser reacts when passing a "misspelled" boolean as a value.
I am importing the express JSON-body parser, which gives me an unexpected behaviour in this specific situation (code sample to run is pasted below). The logs tells me it is the JSON body parser failing because of an unexpected token, which is absolutely fair.
However I am not expecting an HTML body back as a response, which happens here in my case.
Say one were to use this curl command:
Then our response looks great!
The false value here is not encapsulated with quotation marks and is being interpeted correctly. However if we introduce a spelling error, 'false' => 'falsre', I get a HTML body back and no error is actually thrown when the parser fails due to an unexpected token.
So let's do the misspelled boolean value:
Then the response is:
The console then logs this error:
Test code:
Is this the expected behaviour?