Inconsistent uri escaping of Percent (%) in query params in httpx 0.26

[andyjones]

Hi! Thanks for httpx!

I'm trying to make a GET request that has a query parameter that may contain symbols like '%' in them (it is a 3rd party api key) and it is no longer escaped in httpx 0.26.

# The '%' is not escaped so this will raise
import httpx
assert str(httpx.QueryParams({"key": "%"})) == "key=%25"

If the parameter includes other special characters then it does get escaped:

# The '%' does get escaped so this will pass
import httpx
assert str(httpx.QueryParams({"key": "%:"})) == "key=%25%3A"

Digging in a bit further with other combos:

import pytest
import httpx


@pytest.mark.parametrize(
    "raw_params,expected",
    [
        # Passes
        ({"key": ":"}, "key=%3A"),
        ({"key": "/"}, "key=%2F"),
        ({"key": "&"}, "key=%26"),
        ({"key": "?"}, "key=%3F"),
        ({"key": "%:"}, "key=%25%3A"),
        # Fails
        ({"key": "%"}, "key=%25"),
        ({"key": "%P"}, "key=%25P"),
    ],
)
def test_query_params_are_autoescaped(raw_params, expected):
    params = httpx.QueryParams(raw_params)
    assert str(params) == expected

httpx 0.26: fails the tests for {"key": "%"} and {"key": "%P"}
httpx 0.25: all tests pass
httpx 0.24: fails the test for {"key": "/"}

I'm guessing the change of behaviour is related to #2990

Is this expected behaviour going forward?

I couldn't see anything in the docs or tests so apologies if I missed it

[ketpatil77]

Your table passes on HTTPX 0.28.1. In particular, a literal percent sign supplied as a mapping value is encoded as %25:

import httpx

cases = {
    "%": "key=%25",
    "%P": "key=%25P",
    "%:": "key=%25%3A",
    ":": "key=%3A",
    "/": "key=%2F",
    "&": "key=%26",
    "?": "key=%3F",
}
for value, expected in cases.items():
    assert str(httpx.QueryParams({"key": value})) == expected

Pass the original API-key value to params=; do not pre-quote it with quote(), because an already quoted %25 passed as a mapping value is encoded again as %2525. A query string parsed from an existing URL and a mapping of decoded values are different inputs.

This is a version-specific reproduction result, not a promise about every future serialization change. I did not re-run 0.24/0.25/0.26 or identify the release that fixed your historical case. If an upgrade still produces the old behavior, capture httpx.version, the interpreter path, and a non-secret reproduction value rather than printing the real API key. Query parameters.

Validation: HTTPX 0.28.1, Python 3.11.9.