URL Shortening Microservice tests not passing

[kyle4real]

Tell us what’s happening:
I’ve completed the URL Shortening Microservice project, and it works as it’s supposed to, yet two of the four tests are not passing. This happened with he last project, and I was able to solve the issue with a bit of refactoring, but this time I cannot find what seems to be the issue.

Your project link(s)

solution: https://kf-url-shortener-microservice.herokuapp.com
github repo: (i cannot post another link so heres my github username: kyle4real)

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36

Challenge: URL Shortener Microservice

Link to the challenge:

freeCodeCamp.org

[twotani]

Very likely you’re having issues with the dns lookup. Make sure you extract only the hostname from the passed url. FCC tests pass url with a query parameter, something like

https://www.xyz.com/?v=34982873

You need to pass just the hostname portion www.xyz.com to dns.lookup. I created a URL object from req.body.url and pass the hostname urlObj.hostname to dns.lookup method.

[kyle4real]

I appreciate your help! You were right about the passing just the hostname portion to the dns.lookup. The fact that the FCC tests pass in urls with query parameter totally slipped my mind. Once I implemented the changes you suggested, the tests passed, but another test that had initially passed ended up failing (the error response). To fix this, I added the npm package valid-url, and used the .isWebUri to test the passed in url. Without this, a passed url could be verified by dns.lookup even if, for example, the url has a bunch of spaces at the end.

[twotani]

Their tests also pass different protocol like ftp. I believe isWebUri verifies that the protocol is http or https. I use url object for that test also

const purl = new URL(req.body.url)
if (purl.protocol !== 'http:' && purl.protocol !== 'https:') {
    return res.json({'error': 'invalid url'})
}

I didn’t, but you might need valid-url to check of badly formed uri to make the whole thing more robust.