Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Restify req.url broken by #29 #88

Closed
rektide opened this issue Feb 22, 2022 · 2 comments · Fixed by #89
Closed

Restify req.url broken by #29 #88

rektide opened this issue Feb 22, 2022 · 2 comments · Fixed by #89

Comments

@rektide
Copy link
Contributor

rektide commented Feb 22, 2022

Hi, apologies,

In #29, req.path was made preferred to req.url, for finding the url. In restify however req.path is a fucntion (this link is to current master branch). This causes the url not to be logged for restify systems.

@jsumners
Copy link
Member

Would you like to send a Pull Request to address this issue? Remember to add unit tests.

@rektide
Copy link
Contributor Author

rektide commented Feb 22, 2022

Working on it, sure. I plan on testing req.path if present to see if it's a function. This feels like it'll have the highest compatibility, at the cost of some speed. Other implementation suggestions welcome.

rektide added a commit to rektide/pino-std-serializers that referenced this issue 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 issue 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.
mcollina pushed a commit that referenced this issue 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.
Mechanicalkeyboard pushed a commit to Mechanicalkeyboard/pino that referenced this issue Apr 19, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants