Skip to content
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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants