gmaps: keep the /maps/place/ marker when a place URL has a ".." segment

[thejdubb02]

Fixes #320.

What happens now:
Some place links Google returns look like /maps/place/../data=!4m2!3m1!1s0x... The ".." is a normal RFC 3986 dot segment, so when the URL is resolved before the request is made, remove_dot_segments collapses "/maps/place/.." down to "/maps" and the URL becomes /maps/data=!4m2!... The "/maps/place/" marker is gone. Job.Process detects places with strings.Contains(resp.URL, "/maps/place/"), so it no longer recognizes the page as a place, and the detail result is dropped.

Root cause:
The ".." is only special because it is a dot segment. Nothing else in the URL needs to change. If the ".." is replaced with a value that is not a dot segment, normalization leaves the path intact and the marker survives.

The fix:
sanitizePlaceURL rewrites the "/place/../" path segment to "/place/_/" on the raw URL string, and NewPlaceJob applies it to every place URL it builds. Both entry points in job.go route through NewPlaceJob (the resp.URL redirect path and the extracted-href path), so every place URL is covered. It operates on the raw string on purpose: parsing and re-serializing the URL would re-encode the data= payload (the %2F and ! bytes), and this fix must leave that payload byte-for-byte intact. The surrounding slashes require "place" to be a full path segment, so an unrelated path like /myplace/../ is left alone.

Steps to reproduce:

• Feed a place URL of the form https://www.google.com/maps/place/../data=!4m2!3m1!1s0x14e732fd76f0d90d:0xe5415928d6702b47!10m1!1e1 into the pipeline (this is the shape Google returns for some results).
• Before the fix: the URL normalizes to https://www.google.com/maps/data=!4m2!... and the place is not detected, so no detail row is produced.
• After the fix: the URL is https://www.google.com/maps/place/_/data=!4m2!... which normalizes with the /maps/place/ marker intact.

Verification:

• go build ./..., go vet ./..., gofmt, and golangci-lint on the gmaps package are clean.
• Added gmaps/place_url_test.go: a table test through NewPlaceJob covering the ".." case, a ".." case with a %2F-encoded data id (payload preserved byte-for-byte), an ordinary /maps/place// URL left unchanged, a search URL left unchanged, a short URL left unchanged, and a /myplace/../ URL left unchanged. Plus a regression test that resolves the sanitized URL and asserts both the /maps/place/ marker and the data id survive.
• The tests fail without the change (the ".." URL loses its marker under normalization) and pass with it. Ran with -race.

[Copilot]

Copilot review overview

🟡 Changes recommended

The sanitization is not applied to seed URLs handled via NewGmapJob (when the input query is already a Maps URL), so the reported “feed a place URL into the pipeline” scenario can still lose the /maps/place/ marker before place detection runs.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Google Maps seed URLs bypass place URL sanitization · New

What changed in this PR

This PR addresses a Google Maps URL normalization edge case where /maps/place/../data=... loses the /maps/place/ marker during dot-segment removal, causing place pages to be misclassified and their detail results to be dropped.

Changes:

• Sanitize place-detail URLs by rewriting the /place/../ path segment to /place/_/ to prevent RFC 3986 dot-segment collapsing.
• Apply the sanitization in NewPlaceJob so generated place jobs retain the /maps/place/ marker.
• Add table-driven tests and a normalization regression test to ensure the marker and data= payload survive.

File	Description
gmaps/​place.go	Adds sanitizePlaceURL and applies it in NewPlaceJob to preserve /maps/place/ through normalization.
gmaps/​place_url_test.go	Adds tests validating the sanitization behavior and a regression test for URL normalization survival.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.