agent concatenated the base URL with a leading-slash path - double slashes 404d on a strict API

TL;DR

Join the base URL and path with a helper that strips the duplicate slash, and the 404s stop. String-concatenating a trailing-slash base with a leading-slash path produces a double slash that strict routers reject.

Centralize URL building in one helper so every endpoint gets the same joining logic instead of each call site concatenating its own way.

Verbatim query

agent concatenated the base URL with a leading-slash path  -  double slashes 404d on a strict API

Steps

1. Confirm the double slash Log the full request URL for a failing call. Check for a double slash between the host and the path. Expected: The logged URL visibly contains a double slash and the API returns 404 for it.

2. Verify the path without it works Send the same request with the double slash removed. Confirm a 2xx or a different, non-404 error. Expected: The single-slash URL succeeds, proving the double slash was the problem.

3. Add a URL join helper Write one function that strips the trailing slash from the base and the leading slash from the path, then joins with a single slash. Use it everywhere URLs are built. Expected: All request URLs are built through the helper.

4. Replace every concatenation site Search for base URL plus path concatenation across the client. Route each through the helper and delete the ad-hoc joins. Expected: No raw string concatenation of base and path remains.

5. Add a URL-shape test Assert that built URLs never contain a double slash after the scheme. Run it on every regen. Expected: The test passes and would fail if a regen reintroduces raw concatenation.

Use this when

• Requests 404 and the logged URL shows a double slash in the path
• A strict API rejects paths that a lenient one accepted
• Generated code builds URLs by concatenating strings

Not for this skill when

• The 404 happens on single-slash URLs too - the path itself is wrong
• The server normalizes double slashes and still 404s - something else is off
• The double slash is in a query value, not the path - that is an encoding issue

Variant phrasings

double slash in URL 404

Strict routers treat //v1/users and /v1/users as different routes; lenient ones collapse them.

base URL concatenation double slash

Trailing-slash base plus leading-slash path is the classic recipe.

strict API rejects double slashes

If the API 404s on a URL your browser would fix silently, suspect the slashes.

Why it happens

URL joining by string concatenation assumes the two halves agree on slashes, and they rarely do: configs end with a slash, paths start with one. Lenient servers collapse the double slash so nobody notices. Strict routers match the path literally, so the doubled-slash route matches nothing and 404s. One shared join helper removes the assumption entirely.

Edge cases

• Some APIs treat double slashes as a security signal and return 400 instead of 404 - same fix
• Trailing slashes on the full path can also 404 on strict routers; normalize those too
• Proxies and gateways sometimes collapse slashes before the API sees them, hiding the bug in some environments but not others

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bMz66wRVtFB4N4uzY4jC-w