[GH-ISSUE #1729] fix(browser): source map redirects omit the effective resolution URL #580

New issue

Closed

opened 2026-10-15 18:26:23 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:23 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1729

Approved source-map redirects change the URL base used to resolve original source identities, but the result omits that observed terminal URL. The item reports only the script’s declared source-map URL, so consumers cannot reconstruct the derivation base from the delivered evidence.

Reproduced against freshly compiled browser source from main at 092de8f4b336b537579bd48d7d30135b7114371d on Linux / Node.js 24.18.0 using a real loopback HTTP server and production fetchWebSourceMaps, without a browser simulation for the HTTP boundary:

/src/app.js.map responds 302 with Location /maps/v1/app.js.map?revision=2.
The terminal response is a complete v3 map with sources:["../src/original.js"], sourcesContent:["export const value=1;"], and mappings:"AAAA".
Both requests are observed by the server, and both URLs are in the explicitly approved origin.

Observed: the map is included, declared_url still names /src/app.js.map, and original_sources[0].source resolves to /maps/src/original.js. The result’s keys are only script_key, declared_url, artifact, original_sources, original_module_edges, mappings, status, and limitation. No effective URL identifies /maps/v1/app.js.map?revision=2, which actually supplied the source-resolution base.

Expected: preserve the caller/script declaration and the observed effective fetch URL as distinct provenance facts when known. Represent absence explicitly where fetching was not attempted or did not yield a response. Account for the added representation in existing output budgets; do not silently truncate URLs or infer secrecy from parameter names.

The owning boundary already returns {response,fetchedUrl} in WebSourceMapFetcher.fetchFollowingApprovedRedirects. normalizeSourceMap consumes fetchedUrl for source resolution but builds the item from sourceMapContext(request), which only emits the declaration. webBundleAnalysis likewise has no field for the observed URL.

Related: #774 is the broad website roadmap. No specific matching issue or open PR was found with gh. This is a provenance omission, not evidence that current source resolution is incorrect. Local reproduction covers real HTTP redirect/fetch plus the compiled producer; an actual browser or live agent was not exercised.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1729 Approved source-map redirects change the URL base used to resolve original source identities, but the result omits that observed terminal URL. The item reports only the script’s declared source-map URL, so consumers cannot reconstruct the derivation base from the delivered evidence. Reproduced against freshly compiled browser source from `main` at `092de8f4b336b537579bd48d7d30135b7114371d` on Linux / Node.js 24.18.0 using a real loopback HTTP server and production `fetchWebSourceMaps`, without a browser simulation for the HTTP boundary: - `/src/app.js.map` responds 302 with Location `/maps/v1/app.js.map?revision=2`. - The terminal response is a complete v3 map with `sources:["../src/original.js"]`, `sourcesContent:["export const value=1;"]`, and `mappings:"AAAA"`. - Both requests are observed by the server, and both URLs are in the explicitly approved origin. Observed: the map is included, `declared_url` still names `/src/app.js.map`, and `original_sources[0].source` resolves to `/maps/src/original.js`. The result’s keys are only `script_key`, `declared_url`, `artifact`, `original_sources`, `original_module_edges`, `mappings`, `status`, and `limitation`. No effective URL identifies `/maps/v1/app.js.map?revision=2`, which actually supplied the source-resolution base. Expected: preserve the caller/script declaration and the observed effective fetch URL as distinct provenance facts when known. Represent absence explicitly where fetching was not attempted or did not yield a response. Account for the added representation in existing output budgets; do not silently truncate URLs or infer secrecy from parameter names. The owning boundary already returns `{response,fetchedUrl}` in `WebSourceMapFetcher.fetchFollowingApprovedRedirects`. `normalizeSourceMap` consumes `fetchedUrl` for source resolution but builds the item from `sourceMapContext(request)`, which only emits the declaration. `webBundleAnalysis` likewise has no field for the observed URL. Related: #774 is the broad website roadmap. No specific matching issue or open PR was found with `gh`. This is a provenance omission, not evidence that current source resolution is incorrect. Local reproduction covers real HTTP redirect/fetch plus the compiled producer; an actual browser or live agent was not exercised.

bsakaguchi

2026-10-15 18:26:23 +00:00