HttpRequest.url() logs spaces in path segments as literal plus signs
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start with the HttpRequest.url() entry point and inspect how URLEncoder is used for path segments versus query components. Compare its output with the HttpUrl.Builder path handling used by the actual transport and the URL printed by LoggingHttpClient. Done means path spaces appear as %20, query spaces retain + encoding, and literal plus signs remain correctly encoded.
Written by the indexing model from the issue text.
Description
Description
HttpRequest.url() uses URLEncoder for both query components and path segments:
append(URLEncoder.encode(segment, "UTF-8"))
URLEncoder applies form/query encoding semantics, where a space becomes +. That is valid for the query-string usage in the same method, but a + in a URL path is a literal plus character rather than a space escape.
As a result:
HttpRequest.builder()
.method(HttpMethod.GET)
.baseUrl("https://api.example.com")
.addPathSegment("user name")
.build()
.url()
currently returns:
https://api.example.com/user+name
The actual OkHttp transport does not use this string to construct requests. It calls HttpUrl.Builder.addPathSegment("user name"), which sends the path as user%20name. LoggingHttpClient, however, prints request.url(), so the SDK log can show a different request target from the URL that was actually sent.
Expected behavior
HttpRequest.url() should percent-encode spaces in path segments as %20, while preserving the current + encoding for spaces in query parameters.
Impact
This is an observability/debugging correctness issue. Logs produced by LoggingHttpClient can misrepresent path parameters containing spaces, making reproduced requests target a different resource.
Suggested fix
Keep the existing form encoding for query components, but normalize the encoded path-segment result from + to %20. A literal + remains safe because URLEncoder already represents it as %2B.
- Dominant language
- Kotlin
- Stars
- 1.5k
- Forks
- 265
- Avg merge
- 8h 25m
- Merged PRs (30d)
- 142
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/openai-java
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
openai/openai-java#802 · 2 comments · 3 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 74/100
openai/openai-java#973 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
openai/openai-java#956 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
openai/openai-java#952 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
openai/openai-java#889 ·
Maintainers usually reply within 1 day
All issues in openai/openai-java
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
fwcd/tree-sitter-kotlin#289 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
navikt/syfo-oppfolgingsplan-backend#482 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
MorphiaOrg/morphia#4332 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
ooni/probe-multiplatform#1614 · 1 comment ·
Maintainers usually reply within 1 day