This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At the moment, this is listed in the goals, but nowhere else. The implicit assumption is that output of parsing is a canonical URL. If so, that should be stated explicitly. See also: https://annevankesteren.nl/2012/09/url-equivalence This bug was opened on behalf of Larry Masinter, based on: https://github.com/webspecs/url/issues/18
See also: https://github.com/webspecs/url/issues/20, where in addition to "same as", there is a request for "same origin" and "subsumes".
3986 and 3987 both talk about how to compare two URIs, two URIs, for equivalence for various purposes. Neither is entirely accurate or corresponds to current implementation. Every URL processor implicitly defines an equivalence relationship -- two URLs are X-equivalent if they have the same result when processed by X, but comparison generally is predictive, and sometimes being conservative means avoiding false positives and sometimes means avoiding false negatives. comparison. 3986 and 3987 both talk about how to compare two URIs, two URIs, for equivalence for various purposes. Neither is entirely accurate or corresponds to current implementation. Every URL processor implicitly defines an equivalence relationship -- two URLs are X-equivalent if they have the same result when processed by X, but comparison generally is predictive, and sometimes being conservative means avoiding false positives and sometimes means avoiding false negatives. For example, cache invalidation should prefer false positives over false negatives (invalidate if in doubt), while security questions likely prefer false negatives (when in doubt, treat as different origins). Any API for comparison needs to be explicit (or parameterized) about the context presumed (equivalent for what purpose) and how it handles edge cases, illegal values, etc.
https://github.com/whatwg/url/commit/3f0bc8b84d2f3bdb651207ce0f90c659c3a5a573 There's probably still scope for normalization operations that operate on percent-encoded bytes, but for now this seems sufficient and in line with implementations.