Must '@' and '%40' be treated equivalently in URL paths?

Question

Follow up to Can I use an at symbol (@) inside URLs?

Based on the top voted answer, the @ is not a reserved character in the URL path (although it is in the host).

However, given an @ in the path, is the URL-encoded form interchangeable? In other words, is twitter.com/@user strictly equivalent to twitter.com/%40user?

In practice it seems like they're often used interchangeably, but curious if that is strictly the case (e.g. [email protected] is technically different from [email protected], but nearly everyone treats them the same).

More broadly, when do characters and there URL-encoded version need to be treated the same, and when different (e.g. example.com/path%2Fasdf is NOT the same as example.com/path/asdf) …

Answer 1

The URIs http://twitter.com/@user and http://twitter.com/%40user are not equivalent.

---

The URI standard is STD 66, which currently maps to RFC 3986 (which updates RFC 1738).

The section 6.2.2.2. Percent-Encoding Normalization defines how to normalize percent-encoded URIs to compare them for equivalence (after uppercasing hexadecimal digits A-F, as defined by 6.2.2.1 Case Normalization).

It says:

[…] some URI producers percent-encode octets that do not require percent-encoding, resulting in URIs that are equivalent to their non-encoded counterparts. These URIs should be normalized by decoding any percent-encoded octet that corresponds to an unreserved character, as described in Section 2.3.

The linked section 2.3 lists the unreserved characters, which are:

• ALPHA (a-z, A-Z)
• DIGIT (0-9)
• - . _ ~

This sections also states that, even in case no normalization happens:

URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource.

The @ is not part of the "unreserved" set. It’s part of the "reserved" set, where it says:

URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.