[master] prefer req.path instead of req.url.path #29
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mcollina
reviewed
Aug 10, 2020
|
for sure, I post an example code here, I am unable to reproduce by browser or curl, but injecting something weird as URL, I can get the same behavior that I am seeing in my App |
mcollina
reviewed
Aug 11, 2020
lib/req.js
Outdated
| @@ -63,7 +63,7 @@ function reqSerializer (req) { | |||
| _req.url = req.originalUrl | |||
| } else { | |||
| // req.url.path is for hapi compat. | |||
| _req.url = req.url ? (req.url.path || req.url) : undefined | |||
| _req.url = req.path ? req.path : undefined | |||
There was a problem hiding this comment.
Can you please add a fallback that if path is not available we look for url.path
There was a problem hiding this comment.
I had the same feelings about a fallback, but I noticed that Hapi will try to parse the url, and if it is invalid, it will throw the original error, see this line in Hapi, what do you think?
There was a problem hiding this comment.
As far as I understand, Hapi did not have path in a previous release (down to v17 or v18 or maybe even v16). Removing support for req.url is a semver-major change.
I do not understand your question fully maybe.
There was a problem hiding this comment.
well, in order to avoid to bump a major version and keep supporting req.url, we can prefer req.path if it is available, if not, then use req.url.path, like this:
_req.url = req.path || (req.url ? (req.url.path || req.url) : undefined)is better approach?
rektide
added a commit
to rektide/pino-std-serializers
that referenced
this pull request
Feb 22, 2022
in pinojs#29 we preferred req.path, because req.url would throw in hapi if the path was invalid. in restify though, req.path is a function, and this change made the url no longer log. check req.path to see if it is a function, and invoke it if it is.
rektide
added a commit
to rektide/pino-std-serializers
that referenced
this pull request
Feb 23, 2022
restify has a req.path but it's a function that returns an object. rather than try to determine how to handle path if we have it, only use path if it's a simple string. otherwise, keep using req.url, like we used to pre pinojs#29.
rektide
added a commit
to rektide/pino-std-serializers
that referenced
this pull request
Feb 23, 2022
it's tempting to simply stop looking at req.url.path altogether, since that was introduced for hapi 17 in pinojs@83d58a7#diff-2c4782cb20f7f0d7ca90c7bc04939f4420c4bdb42fdce618984da393ba9202f7R60 . but since pinojs#29 we look at req.path first, which is safer in hapi, so hapi doesn't care about req.url.path anymore. but perhaps someone else does depend on req.url.path . so for now, continuing to look at req.url.path , which means a bit more guarding in the req serializer.
rektide
added a commit
to rektide/pino-std-serializers
that referenced
this pull request
Feb 23, 2022
it's tempting to simply stop looking at req.url.path altogether, since that was introduced for hapi 17 in pinojs@83d58a7#diff-2c4782cb20f7f0d7ca90c7bc04939f4420c4bdb42fdce618984da393ba9202f7R60 . but since pinojs#29 we look at req.path first, which is safer in hapi, so hapi doesn't care about req.url.path anymore. but perhaps someone else does depend on req.url.path . so for now, continuing to look at req.url.path , which means a bit more guarding in the req serializer.
This was referenced Feb 23, 2022
mcollina
pushed a commit
that referenced
this pull request
Feb 23, 2022
* call req.path() if a function. restify compat, fixes #88 in #29 we preferred req.path, because req.url would throw in hapi if the path was invalid. in restify though, req.path is a function, and this change made the url no longer log. check req.path to see if it is a function, and invoke it if it is. * add test for calling req.path() if it is a function. * only get url from req.path if it's a string. fixes #88. restify has a req.path but it's a function that returns an object. rather than try to determine how to handle path if we have it, only use path if it's a simple string. otherwise, keep using req.url, like we used to pre #29. * guard against req.url being falsy it's tempting to simply stop looking at req.url.path altogether, since that was introduced for hapi 17 in 83d58a7#diff-2c4782cb20f7f0d7ca90c7bc04939f4420c4bdb42fdce618984da393ba9202f7R60 . but since #29 we look at req.path first, which is safer in hapi, so hapi doesn't care about req.url.path anymore. but perhaps someone else does depend on req.url.path . so for now, continuing to look at req.url.path , which means a bit more guarding in the req serializer.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix #28