Fix restify (#88) by only using req.path if a string #89
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
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.
|
Crud, issue is slightly hairier. Converted to draft temporarily. In restify, |
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.
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
changed the title
# 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.
only use
req.pathif it is a string. this is for restify compatibility; fixes #88.in #29 we preferred
req.path, becausereq.urlwould throw in hapi if the path was invalid.in restify though,
req.pathis a function (which returns a parsed url object). so after #29, restify stopped logging url.in this pr, we check
req.pathto see if it is a string before using it. else we go back to usingreq.url. alternatively, we could have checked if path was a function, then checked if the object returned had a path element, but simply being more specific about whatreq.path's we accept was preferred as it reduced the amount of branches the code would take.i have also added a check for
req.urlbeing undefined, as i nearly hadn't considered that case & almost left the code in a broken/error-throwing state then.req.url.path
side discussion- we could possibly simplify more, see rektide#2 which i am happy to do.
right now, this pr still leaves in an attempt to use
req.url.path, which was introduced to support hapi a number of years ago. since we now usereq.pathto better/more-safely support hapi (as of #29), we could consider removingreq.url.pathchecking: these old checks are redunant. hapi has supportedreq.pathsince before 2013's v1.0.0 so no risk there.yet there may be people in the world other than hapi who have grown to expect
req.url.path. i tend to doubt that, and it's tempting to accept that risk & simplify/drop thereq.url.pathcheck, but i have left it intact for now. happy to do whatever folks want.