Render a URL that is a URL - #31
Merged
Merged
Conversation
Found by running the thing rather than reading it. The Search Box API takes
free text now, so this is an ordinary call:
mapbox search forward --q "Dog friendly coffee shops near me" \
--proximity -77.0336,38.8996
It works. The URL printed beside it did not:
[debug] GET …/forward?access_token=<redacted>&q=Dog friendly coffee shops near me&…
$ curl "<that>"
HTTP 000
`curl` makes no request at all. A line whose entire purpose is "here is what
was sent, go try it" could not be tried, and free-text queries are the case
that breaks it.
`redacted_url` concatenated `name=value` pairs raw. The request was never
affected — reqwest encodes what it sends, which is why the call succeeded and
the printout beside it lied. Two renderings shared the function: `--debug`
and a text-mode `--dry-run`. A JSON dry run keeps `url` and `query` as
separate fields, so it never had the problem.
**Also: a value could invent a parameter.** One containing `&` split into
another pair, so the line claimed the request carried something it did not,
and anyone pasting it sent a different request than the one being debugged.
`=` and `+` are the same class. That is the second test.
`%20` rather than form-urlencoding's `+`: both decode to a space wherever the
query is read as a form, but only `%20` means a space everywhere else, and a
`+` in a URL someone is reading is a character they have to stop and think
about. `,` `:` `/` and `@` stay literal — they are legal in a query and they
are what make `proximity=-77.0336,38.8996` readable.
No new dependency: `reqwest::Url` was already used in this file, and the
encoder is nine lines with the kept set spelled out.
Verified end to end: the printed URL, with a real token substituted for the
placeholder, returns HTTP 200 and the same two features the CLI printed. Both
new tests confirmed to fail with the encoding reverted.
599 tests, fmt and clippy clean.
Only CHANGELOG.md conflicted. #26's Added entry and its Fixed entry both belong alongside this branch's Fixed entry, so the section is one Added and one Fixed holding both. No source change was involved.
zmofei
approved these changes
Sep 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by running the thing. The Search Box API takes free text now, so this is an ordinary call:
mapbox search forward --q "Dog friendly coffee shops near me" --proximity -77.0336,38.8996It works. The URL printed beside it did not:
A line whose whole purpose is "here's what was sent, go try it" couldn't be tried — and free-text queries are exactly the case that breaks it.
Only the printout was wrong
redacted_urlconcatenatedname=valuepairs raw. The request itself was never affected: reqwest encodes what it sends, which is why the call succeeded while the line beside it was unusable.Two renderings share that function —
--debug, and a text-mode--dry-run:A JSON dry run keeps
urlandqueryas separate fields, so it never had the problem.A value could also invent a parameter
This is the half that's worse than ugly. A value containing
&split into anothername=valuepair, so the line claimed the request carried something it didn't, and anyone pasting it sent a different request than the one being debugged.=and+are the same class. That's the second test:Choices worth stating
%20, not form-urlencoding's+. Both decode to a space wherever the query is read as a form, but only%20means a space everywhere else, and a+in a URL someone is reading is a character they have to stop and think about.,:/@stay literal. They're legal in a query and they're what keepsproximity=-77.0336,38.8996readable instead of-77.0336%2C38.8996.No new dependency.
reqwest::Urlwas already used in this file, and the encoder is nine lines with the kept set spelled out.Verified end to end
The printed URL, with a real token substituted for the placeholder:
Same two features the CLI itself printed. Both new tests confirmed to fail with the encoding reverted.
599 tests, fmt and clippy clean.