js-debug should follow redirects when requesting sourcemaps

In my setup, the vscode debugger extension can’t load the source map for the browser app bundle anymore, even though it always used to work in previous versions of vscode. The error message given is Could not read source map for http://127.0.0.1:8080/App.d4a65e86.js: Unexpected end of JSON input.

Trace log is attached: vscode-debugadapter-1.json.gz

launch.json entry (probably not related, though) – chrome-helper.sh just launches a specific version of Chromium with a set of debugging extensions installed, so that we can share the setup more easily across the team. The path override is just necessary to map the files in the source map to local files, but it’s most definitely unrelated to this issue.

{
      "name": "Debug in Chromium",
      "type": "chrome",
      "request": "launch",
      "url": "http://127.0.0.1:8080/",
      "runtimeExecutable": "${workspaceRoot}/.vscode/chrome-helper.sh",
      "webRoot": "${workspaceRoot}/src",
      "smartStep": true,
      "sourceMaps": true,
      "sourceMapPathOverrides": {
        "../*": "${webRoot}/*"
      }
    }

VS Code Version: 1.47.1 on macOS 10.15.4

Additional info: The source map itself is fine, valid JSON, and works in the browser itself, and it used to work well in older versions of vscode, too. The error message given is Could not read source map for http://127.0.0.1:8080/App.d4a65e86.js: Unexpected end of JSON input.

I suspect it is because the source map URL is a redirect to the actual URL, which the new debugger can’t seem to deal with. Here’s the output of curl when you request the source map, as the debugger sees it.

As you can see, it requests source map at /, but gets redirected to /app. This should, however, be allowed, I think, and works fine with browsers and older versions of the debugger, so I have a strong suspicion that maybe the redirect is what causes the confusion, and the “Unexpected end of JSON input” error is bogus, because the redirect response does not contain a body.

Unfortunately, I can’t share the source map itself (since the app is not open-source), but please take my word that the source map itself is perfectly valid 😃

gck@tenenbaum$ curl -Ivvv 'http://127.0.0.1:8080/App.d4a65e86.js.map'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> HEAD /App.d4a65e86.js.map HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< content-length: 0
content-length: 0
< location: /app/App.d4a65e86.js.map
location: /app/App.d4a65e86.js.map
< connection: keep-alive
connection: keep-alive
< date: Wed, 22 Jul 2020 09:34:07 GMT
date: Wed, 22 Jul 2020 09:34:07 GMT

< 
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

[gkaindl]

Just a quick update: It turned out that there was a bug in SwiftNIO that would cause a part of the compressed response to be missing in a specific code path, and that would cause a non-stream-oriented decompressor to choke when decompressing it – which is what happened to got.

The issue has been resolved now, so I don’t think an option to load source maps with Accept-encoding: identity is needed anymore!

Thank you for your help in looking into this!

[gkaindl]

Thanks for putting it into the milestone! 😃

In the mean time, I’ve adapted the debug build of my backend to deliver the source map without a redirect, and I can confirm that this was/is the problem, so following redirects should fix it!