getWSEndpoint drops browserURL path prefix when resolving /json/version

Finding: In Puppeteer's BrowserConnector getWSEndpoint, a browserURL that includes a path prefix (for example http://host:9222/t/token behind a reverse proxy or tunnel) is reported to lose that prefix when puppeteer.connect discovers the WebSocket endpoint. The affected version is UNKNOWN. This is an external report and was not reproduced by KFA. Reported symptom: the HTTP discovery request goes to http://host:9222/json/version rather than under /t/token/json/version, per the issue body (https://github.com/puppeteer/puppeteer/issues/15250). No explicit error string is given; the failure is a wrongly routed request. The reporter also notes that chrome-devtools-mcp, which bundles Puppeteer and exposes --browserUrl, is affected. Reported cause: the code builds the URL with new URL('/json/version', browserURL). Because the path starts with a slash, WHATWG URL resolution replaces the whole base pathname (issue body, https://github.com/puppeteer/puppeteer/issues/15250). A commenter said the same line was still present on main, in packages/puppeteer-core/src/common/BrowserConnector.ts, and checked it with plain URL logic and no browser (https://github.com/puppeteer/puppeteer/issues/15250#issuecomment-5883808378). That is a community analysis, not a maintainer-confirmed cause. Proposed mitigation (hypothesis in the source): copy browserURL into a URL object and append json/version to the existing pathname, normalizing to a single trailing slash. The commenter said this holds with and without a trailing slash and with a query string, and warned that a relative-URL one-liner breaks when a query string is present (comment 5883808378). This was checked only by that commenter's URL logic. Adjacent caveat from the same commenter: the webSocketDebuggerUrl returned by /json/version is built by Chrome from the Host header, so behind a path-rewriting proxy it may still lack the prefix. The commenter considered this the proxy's responsibility and separate from this issue (comment 5883808378). Fix status: a COLLABORATOR commented on 2026-10-01 that the issue was fixed and linked PR 15435 (https://github.com/puppeteer/puppeteer/issues/15250#issuecomment-5930740321). The issue is closed, but PR content, merge status and the release containing it were not supplied, so the shipped fix and fixed version are unverified. No workaround was stated by the source. Limitations: external reports only; no KFA reproduction; affected and fixed versions unknown; comment coverage may omit middle comments.