You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on documentation and WHATWG URL API new URL() accepts a string as input. By tests i figured out that an array with single string is also accepted as seen here:
i understand this might be accepted but an array with 2 strings is not accepted, more problematic, it returns a VALID URL which should NOT be valid (see screenshot). Moreover same situation applies to Chrome, Firefox (latest versions).
This behaviour might cause a security issue, since especially passing an array with 2 strings does not throw any INVALID_URL error like the 4th case in the screenshot. People might inject stuff and this validation would fail. Even though this might be minor issue on browser, at the server-side this might be major thing
How often does it reproduce? Is there a required condition?
This is perhaps a documentation bug but not a bug in the code.
The spec indicates that new URL() accepts a USVString. Any non-string JavaScript value sent to an API that accepts a USVString is first stringified. So, for the most part, any non-string value that has a toString() function is treated as if it is the value returned by that toString() function. So sending ['https://example.com'] is the same as sending 'https://example.com'.
MDN indicates that new URL() should accept any object with a stringifier.
I tested in Chrome and it happily accepts an array.
Reacted by Luigi Pinca, Benjamin Gruenbaum and Darshan Sen
As this isn't up to us but the URL standard (as explained by Rich and confirmed by James above - and if you're interested you can check the conversions in the WebIDL spec) - I think it's not something Node can/should fix.
Activity
Trott commentedon Jan 22, 2022
This is perhaps a documentation bug but not a bug in the code.
The spec indicates that
new URL()accepts a USVString. Any non-string JavaScript value sent to an API that accepts a USVString is first stringified. So, for the most part, any non-string value that has atoString()function is treated as if it is the value returned by thattoString()function. So sending['https://example.com']is the same as sending'https://example.com'.MDN indicates that
new URL()should accept any object with a stringifier.I tested in Chrome and it happily accepts an array.
Trott commentedon Jan 22, 2022
@nodejs/url
jasnell commentedon Jan 22, 2022
@Trott's explanation is correct. There's no bug here. The behavior is correct.
benjamingr commentedon Jan 24, 2022
As this isn't up to us but the URL standard (as explained by Rich and confirmed by James above - and if you're interested you can check the conversions in the WebIDL spec) - I think it's not something Node can/should fix.
If you feel strongly about this - please open an issue in the https://github.com/whatwg/url repo
As usual - if anyone feels this should be reopened please do so.
Trott commentedon Jan 24, 2022
Doc change to clarify this: #41658
benjamingr commentedon Jan 24, 2022
Let's reopen until the doc clarification at #41658 lands then I missed that
doc: clarify treatment of non-string argument to new URL()
doc: clarify treatment of non-string argument to new URL()
doc: clarify treatment of non-string argument to new URL()
doc: clarify treatment of non-string argument to new URL()
doc: clarify treatment of non-string argument to new URL()