-
Notifications
You must be signed in to change notification settings - Fork 9
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
Deprecate url.parse API in favor of URL constructor #11
base: master
Are you sure you want to change the base?
Changes from 4 commits
603fd51
363dda7
279a5fa
1fbc6b3
fdad8c3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,12 @@ | ||
'use strict' | ||
|
||
const parseUrl = require('url').parse | ||
const URL = require('url').URL | ||
const parseForwarded = require('forwarded-parse') | ||
const net = require('net') | ||
|
||
module.exports = function (req) { | ||
const raw = req.originalUrl || req.url | ||
const url = parseUrl(raw || '') | ||
const url = parsePartialURL(raw) | ||
const secure = req.secure || (req.connection && req.connection.encrypted) | ||
const result = { raw: raw } | ||
let host | ||
|
@@ -92,7 +92,14 @@ function getFirstHeader (req, header) { | |
|
||
function parsePartialURL (url) { | ||
const containsProtocol = url.indexOf('://') !== -1 | ||
const result = parseUrl(containsProtocol ? url : 'invalid://' + url) | ||
if (!containsProtocol) result.protocol = '' | ||
const urlInstance = new URL(containsProtocol ? url : 'invalid://' + url) | ||
const result = {} | ||
for (const prop in urlInstance) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Preferred to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven't run tests, but I believe you can just pass back the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see that the
What about pulling the if (url.protocol) result.protocol = url.protocol to this: if (url.protocol !== INVALID_PROTO) result.protocol = url.protocol Then one should be able to avoid copying the URL properties to a new object. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just realised other parts of the logic rely on the mutability of the URL object properties to resolve some values like the protocol. So either we complicate the main logic or we keep the property copy. Performance wise I guess 1st option would be the one to pick.
Do you mean to use a value which is longer and more unlikely to be used by consumers? Something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did some changes following your advice @trentm
Something I've noticed in the tests is that |
||
if (typeof urlInstance[prop] !== 'function') result[prop] = urlInstance[prop] | ||
} | ||
if (!containsProtocol) { | ||
result.protocol = '' | ||
result.href = result.href.replace('invalid://', '') | ||
} | ||
return result | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could throw where
url.parse
would not throw before, e.g.:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
I think the legacy
parse
method is much more permissive since it consists on a loop trying to figure out as much as possible from the input string. You can look at the implementationThis means there will be more cases where the WHATWG URL API would simply throw since the input does not conform to its specs.
I guess the best approach to do not drop support is to catch the error and fallback to the legacy so we ensure support to package consumers which make use of this edge cases.