Code change:
4.2.3. <del> Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to the algorithm defined in RFC3986, using the defaults described above for each scheme. If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent.  When not being used as the target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead.  The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.  Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections RFC3986 and RFC3986 of RFC3986). </del> <ins> The "http" and "https" URI are normalized and compared according to the methods defined in RFC3986, using the defaults described above for each scheme. HTTP does not require use of a specific method for determining equivalence.  For example, a cache key might be compared as a simple string, after syntax-based normalization, or after scheme-based normalization. Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to identify the same resource, and any HTTP component MAY perform normalization.  As a result, distinct resources SHOULD NOT be identified by HTTP URIs that are equivalent after normalization (using any method defined in RFC3986). Scheme-based normalization (RFC3986) of "http" and "https" URIs involves the following additional rules: </ins> For example, the following three URIs are equivalent:

Related discussion:
text: Would it be feasible to spec that equivalent URIs simply do identify the same resource, and if different representations are returned for different forms, it's a strange but unambiguously identifiable resource? (That's exactly already the semantics for URIs resolved by servers using their file systems,which is the most popular method. If there's an RSS feed at , then the file gets deleted, and after some time a new webmaster (possibly even not knowing that there used to be an RSS feed) places an icon (like ) there (and configures the appropriate ), the resource doesn't change. It's just a weird resource whose representation (independent of other factors, thus no ) is an RSS feed for some period, then it has no representation ( or ), and still later it's represented by an icon.) It doesn't break backward compatibility with implementations doing crazy things, those things remain technically spec compliant, it just pinpoints the semantics, saying that, despite possibly different representations, some things are the same resource (which current specs leave unclear, so some might have assumed otherwise, but, as I wrote above, it's such a corner case that I'd be surprised to learn that somebody actually not only held this interpretation, but also relied on it). The added burden of compliance to the stricter semantics is on people minting URIs for resources. And if they're unaware of normalization, we'd actually do them a favour by defaulting to the anyway likely desirable thing – having all those other equivalent forms of the URI identify the same resource (and yield the same representation, unless they put enough effort to circumvent normalization and have different representations for the same resource depending on which of the equivalent URIs was used, but doing that indicates they do know of this stuff). One more nit. Is normalization all or nothing? Or are HTTP components allowed to e.g. only omit port 80 and keep dot segments? I think it should be specified and prefer the former (which also follows Postel's law), though I realize there may be popular implementations doing otherwise; if so, a SHOULD is probably the most that could be counted on. (For completeness: are they allowed to denormalize, e.g. introduce case variation in the authority part?)