fix: Fixed double decoding issue with unquote()

[vladvildanov]

Description of change

ConnectionPool.from_url (and everything that routes through parse_url — Redis.from_url, the sync/async cluster clients, and Sentinel) percent-decodes URL query values twice, corrupting any value that contains a literal percent-encoded sequence.

urllib.parse.parse_qs() already percent-decodes the values it returns, but parse_url then called urllib.parse.unquote() on the result a second time:

for name, value in parse_qs(url.query).items():                                                                                                                                                                
    if value and len(value) > 0:                                                                                                                                                                               
        value = unquote(value[0])   # ← second, erroneous decode

Fix

Drop the redundant second decode in both stacks and use the value parse_qs already returned:

• redis/connection.py — parse_url()
• redis/asyncio/connection.py — parse_url()

The unquote() calls on username, password, path, and hostname are intentionally left unchanged: urlparse() does not decode those components, so those are the correct single decode. + handling is also unaffected — parse_qs already applies form-encoding semantics (+ → space), and unquote never touched +.

Pull Request check-list

Please make sure to review and check all of these items:

• Do tests and lints pass with this change?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

---

Note

Low Risk
Narrow URL parsing fix with targeted tests; behavior change only for query values that were incorrectly double-decoded.

Overview
Fixes double percent-decoding of query-string values in parse_url() for sync and async connection URLs (redis://, rediss://, unix://), including ConnectionPool.from_url / Redis.from_url and other callers of that helper (#4208).

Query parameters were passed through urllib.parse.unquote() after parse_qs() had already decoded them, so values like client_name=worker%2520name became a space instead of the intended literal %20. The redundant unquote is removed; username, password, path, and hostname still use unquote because urlparse does not decode those parts.

Sync and asyncio connection-pool tests cover single decode (worker%20name → space) and no second decode (worker%2520name → worker%20name).

^{Reviewed by Cursor Bugbot for commit 2af8435. Bugbot is set up for automated code reviews on this repo. Configure here.}

[winklemad]

Thanks for the quick turnaround, @vladvildanov. The fix looks correct to me. parse_qs already percent-decodes the values it returns (and folds + to a space), so the follow-up unquote() was a genuine second decode. Walking the exact change through with the issue's input: parse_qs("client_name=worker%2520name") gives back worker%20name, the old unquote() turned that into worker name, and dropping it keeps worker%20name — which is the result the issue expected. The two regression tests pin down both the decode-once and don't-decode-twice cases.

I also went through the surrounding paths to be sure the scope is right: the username/password/host and the unix path branches still call unquote() once each, and that's correct — urlparse hands those back still-encoded, so they each need exactly one pass. The query loop was the only spot getting a decode from parse_qs and a second one from unquote, so this is the right (and only) place to touch.

One pre-existing thing I noticed while reading, not for this PR: since parse_qs folds + into a space, a literal + in a query value comes out as a space, whereas a + in the userinfo stays a +. That's standard form-decoding and out of scope here — just flagging it in case it's ever worth a line in the docs. LGTM.