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: The text on doesn't assign any behaviours to roles; it just passively states that http(s) URIs 'are' normalised and compared. This leads to some confusion about what roles are responsible for normalising. E.g., can a server consider and as two different target URIs? I think we all agree on the answer to that, but it isn't clearly stated in the specs AFAICT.
I'm not sure about that example (as a browser would never emit the latter), but they can certainly rely on some of the other variants and have been known to do so.
We currently just point to URL - so "path segment normalization" is something that may or may not happen, depending on who's doing the comparison. My answer would be "a server could do that, but it would be stupid". What's your take?
I agree with your answer, but think we should say something about it -- perhaps going as far as saying a server should/must not do that (as it's not interoperable).
Security is probably a stronger reason not to allow in request targets. Another reason that specific example, as opposed to '+' vs '%20', might be a bad idea.
see also URL
I think the comment is more confusing than the spec. The request target is whatever is provided by the client. If the server responds to the second example target with a 301/302 to the first, then it does consider them to be two different target URIs for the same resource. In practice, that is the best way to respond because it forces the client to change its own copy of the target URI before it makes the "right" request. IIRC, that what we do in Apache httpd. This type of response is not canonicalization -- it's reasonable handling of an unsafe target without breaking the intended request. We might call that responsible handling after the client fails to canonicalize a reference, but keep in mind that a ".." path segment only has meaning for relative references (not references that are already in absolute form). In any case, a client is not required to canonicalize beyond resolving of relative form to absolute form. Some other servers might want to respond with 403 (e.g., an authoring server responding to a link checker). That's okay too.