RFC 3986 section 2.1 explains:
> If two URIs differ only in the case of hexadecimal digits used
> in percent-encoded octets, they are equivalent.

And RFC 3986 section 6.2.1 on "Simple String Comparison" states:
> Testing
> strings for equality is normally based on pair comparison of the
> characters that make up the strings, starting from the first and
> proceeding until both strings are exhausted and all characters are
> found to be equal, until a pair of characters compares unequal, or
> until one of the strings is exhausted before the other.
>
> This character comparison requires that each pair of characters be
> put in comparable form.

Putting the above two quotes together, a simple string comparison
in URIs aould be done on the "character", which for percent-encoded
octets means the original character, where the percent-encoded octets
might still differ in case but encode the same character.  E.g.,
can be expressed as either %3C or %3c both indicate the same character.

Section 6.2 discusses a comparison ladder that gives leeway in
spending more computation to lower the risk of false negatives.
Following the rule quoted in section 2.1 could be seen as one such
step.

In contrast, RFC 6265 section 5.1.4 states
"A request-path path-matches a given cookie-path if at least one of
 the following conditions holds:

 o The cookie-path and the request-path are identical."

This section does no case normalization, nor any case-insensitive
comparison of the path. The path is case sensitive and the comparison
is for "identical".  That is, it uses the simplest ladder comparison
possible, at the expense of false negatives. As a result,
equivalent URIs, such as those that differ only in the case of
hexadecimal digits used in percent-encoded octets, can have
different cookies. This can lead to developer confusion, and to
protocol inefficiencies as cookies must be managed for every variant
that is used.