Release 1.25.4 has a behavior change due to #1673 -- tilde characters in URLs are now percent-encoded. Some remote systems may not decode path components if they are not expecting any input other than unreserved characters. In such cases, this behavior change may cause user-visible errors.
The text was updated successfully, but these errors were encountered:
Recently merged urllib3#1673 ensured that URLs are percent-encoded.
This is a behavior change in that URLs with tilde characters in
them would not previously have been percent-encoded, but are now.
RFC 3986 says:
For consistency, percent-encoded octets in the ranges of ALPHA
(%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
underscore (%5F), or tilde (%7E) should not be created by URI
producers and, when found in a URI, should be decoded to their
corresponding unreserved characters by URI normalizers.
This suggests that urllib3 should not escape tilde characters
in URLs. The RFC describes tilde as an "unreserved" character.
Among the character classes at the top of url.py, the closest
match to the "unreserved" set seems to be ZONE_ID_CHARS. RFC6874
A <zone_id> SHOULD contain only ASCII characters classified as
"unreserved" for use in URIs [RFC3986].
Which suggests that it should be safe to add to that set.
Because we do the call with /amqptest/utcontainer6826924cfebd44dc847eac07516e17c1/~a~a~, so we encode our signature with the ~ string, and the service actually receives a %7E string.
Just to be sure you don't get my message wrongly: maybe you do the right thing and Azure is wrong here in pure term of HTTP spec, but at least as @jeblair said that's a change of behavior in a bugfix version and definitely breaks people :(