Consider making URL's context symbol more private, or at least resetting the "flags" member #24211
Labels
help wanted
Issues that need assistance from volunteers or PRs that need help to proceed.
whatwg-url
Issues and PRs related to the WHATWG URL implementation.
Comments
devsnek
added
the
whatwg-url
|
sgtm, we already use WeakMap elsewhere in core for this. |
|
Does IDL tests in WPT cover this? This is what I got from #24035 but I have not taken a closer look |
|
Minimal test case with our assert: const assert = require('assert');
assert.deepStrictEqual(
new URL('./foo', 'https://example.com/'),
new URL('https://example.com/foo')
); |
|
I looked into this a bit further - going hard-private in URL/URLSearchParams seems more complicated than I thought. For one, the symbol properties are displayed in |
3 tasks
Trott
pushed a commit
to Trott/io.js
that referenced
this issue
Nov 9, 2018
At the moment we expose the context as a normal property on the prototype chain of URL or take them from the base URL which makes them enumerable and considered by assert libraries even though the context carries path-dependent information that do not affect the equivalence of these objects. This patch fixes it in a minimal manner by marking the context non-enumerable as making it full private would require more refactoring and can be done in a bigger patch later. PR-URL: nodejs#24218 Refs: nodejs#24211 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
BridgeAR
pushed a commit
that referenced
this issue
Nov 14, 2018
At the moment we expose the context as a normal property on the prototype chain of URL or take them from the base URL which makes them enumerable and considered by assert libraries even though the context carries path-dependent information that do not affect the equivalence of these objects. This patch fixes it in a minimal manner by marking the context non-enumerable as making it full private would require more refactoring and can be done in a bigger patch later. PR-URL: #24218 Refs: #24211 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
kiyomizumia
pushed a commit
to kiyomizumia/node
that referenced
this issue
Nov 15, 2018
At the moment we expose the context as a normal property on the prototype chain of URL or take them from the base URL which makes them enumerable and considered by assert libraries even though the context carries path-dependent information that do not affect the equivalence of these objects. This patch fixes it in a minimal manner by marking the context non-enumerable as making it full private would require more refactoring and can be done in a bigger patch later. PR-URL: nodejs#24218 Refs: nodejs#24211 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
Adding a |
Trott
added
the
help wanted
|
FTR I tried prototyping with WeakMaps but the performance regression was a bit uh....unacceptable (45 It would still be nice to have a general refactoring in |
TimothyGu
added a commit
to TimothyGu/node
that referenced
this issue
Nov 19, 2018
Trott
pushed a commit
to Trott/io.js
that referenced
this issue
Dec 1, 2018
Fixes: nodejs#24211 PR-URL: nodejs#24495 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
|
Fixed in 639f641 |
BridgeAR
pushed a commit
that referenced
this issue
Dec 5, 2018
Fixes: #24211 PR-URL: #24495 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
codebytere
pushed a commit
that referenced
this issue
Dec 14, 2018
At the moment we expose the context as a normal property on the prototype chain of URL or take them from the base URL which makes them enumerable and considered by assert libraries even though the context carries path-dependent information that do not affect the equivalence of these objects. This patch fixes it in a minimal manner by marking the context non-enumerable as making it full private would require more refactoring and can be done in a bigger patch later. PR-URL: #24218 Refs: #24211 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
MylesBorins
pushed a commit
that referenced
this issue
Dec 26, 2018
At the moment we expose the context as a normal property on the prototype chain of URL or take them from the base URL which makes them enumerable and considered by assert libraries even though the context carries path-dependent information that do not affect the equivalence of these objects. This patch fixes it in a minimal manner by marking the context non-enumerable as making it full private would require more refactoring and can be done in a bigger patch later. PR-URL: #24218 Refs: #24211 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
refack
pushed a commit
to refack/node
that referenced
this issue
Jan 14, 2019
Fixes: nodejs#24211 PR-URL: nodejs#24495 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
BethGriggs
pushed a commit
that referenced
this issue
Feb 12, 2019
Fixes: #24211 PR-URL: #24495 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
rvagg
pushed a commit
that referenced
this issue
Feb 28, 2019
Fixes: #24211 PR-URL: #24495 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The (WHATWG) URL object's internal "context" symbol is exposed as an enumerable property on
URLinstances. This leads to it being considered for comparison by testing frameworks and the like.For example, see https://repl.it/repls/StaidUnlinedFolder, wherein Jest considers
new URL('./foo', 'https://example.com/')andnew URL('https://example.com/foo')different because the former has flags: 496, and the latter has flags: 400.The best solution would probably be using WeakMaps, or V8 private symbols. But you may be able to just make the
url[context]property non-enumerable, and maybe that would placate Jest? Or even just reseturl[context].flagsafter you're done parsing, so that even if your internals are exposed, you don't have this weird path-dependence./cc @nodejs/url
The text was updated successfully, but these errors were encountered: