Reject non-IPv4 hostnames that end in numbers
Categories
(Core :: Networking, task, P3)
Tracking
()
People
(Reporter: valentin, Assigned: edgul)
References
(Blocks 5 open bugs, )
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
See https://github.com/whatwg/url/pull/619
If the last component of a URL's hostname is numeric, it's parsed as an IPv4 hostname, and if that fails, the URL's host is rejected. e.g., "foo.0", "bar.0.09", "a.1.2.0x.", "1.2.3.4.5" were all previously considered valid non-IPv4 hostnames, but are now all rejected.
Reporter | ||
Comment 1•2 years ago
|
||
Most of the fix needs to go here.
We want to return an error code from BuildNormalizedSpec if the hostname ends in a number, but does NormalizeIPv4 returns an error code.
We have a bunch of failing WPT for this in failure.html - see bug 1722328.
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
If we follow the spec and properly ignore the last dot, this should also fix
Origin parsing: <http://999999999.> against <http://other.com/>
Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
Assignee | ||
Comment 5•1 year ago
|
||
Latest try run looks like we might be able to land:
https://treeherder.mozilla.org/jobs?repo=try&revision=a381641bfb9d0f5452a9ce574c95c74dea6d8f42&selectedTaskRun=Hb9BWGT4TYO8yh7NGHyetw.0
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Description
•