-
-
Notifications
You must be signed in to change notification settings - Fork 665
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
prettyJSON throws on invalid query parameters #3952
Comments
This patch should work:
I can put this into a PR & test if the maintainers are open to it |
Hi @lincolnremi Thank you for the issue! Good catch. But please wait a bit. Hey @usualoma ! What do you think of the following? Not only a Pretty JSON middleware case, but I wonder whether it is correct behavior to get a In the case of Express, instead of throwing an error, the invalid query is treated as a string. The app code: const express = require('express')
const app = express()
app.get('/', (req, res) => {
const foo = req.query.foo
res.send(`foo: ${foo}`)
})
app.listen(3000, () => {
console.log('Server is running on port 3000')
}) The results: $ curl 'localhost:3000?foo=%E3%81%82'
foo: あ%
$ curl 'localhost:3000?foo=%E3%81%8'
foo: %E3%81%8% But the Hono app: import { Hono } from 'hono'
const app = new Hono()
app.get('/', (c) => {
const foo = c.req.query('foo')
return c.text(`foo: ${foo}`)
})
export default app Perhaps we should follow the same spec as Express? $ curl 'localhost:3000?foo=%E3%81%82'
foo: あ%
$ curl 'localhost:3000?foo=%E3%81%8'
Internal Server Error% |
Express relies on query parser libraries such as qs. |
I also think it would be good if the result here was the same as with the express. $ curl 'localhost:3000?foo=%E3%81%82'
foo: あ
$ curl 'localhost:3000?foo=%E3%81%8'
foo: %E3%81%8 I think it would be better if users defined and used their own custom query parser. I think it is more likely that users want to use their own parser because they want to define their own type, so I think it would be better if they defined it themselves rather than incorporating it into the hono. const foo = new myCustomQuery(c).get(‘foo’) |
Thank you for the comments! Regarding the custom query parser, I prefer to use the syntax @usualoma suggested. myCustomQuery(c).get(‘foo’) But we should discuss implementing the same behavior with Express for the default. Of course, the user can change the behavior with the custom query parser, but almost all users do not use it, and the default behavior is important. We can treat the difference between Hono's and Express's as a bug or unexpected behavior. I think we should make it so that the error is not thrown if I want to know what you think. |
What version of Hono are you using?
4.7.2
What runtime/platform is your app running on? (with version if possible)
NodeJS v20.16.0
What steps can reproduce the bug?
prettyJSON calls
HonoRequest.query()
without a try clause, so when an invalid query parameter is passed, it throws theURIError: URI Malformed
error.Here is the code:
This code was obtained by running
npm create hono@latest
and adding two lines for importing and using prettyJSON.What is the expected behavior?
It should not throw an error
What do you see instead?
Making requests to the server throws the error as follows:
And the server logs:
Additional information
No response
The text was updated successfully, but these errors were encountered: