Uh oh!
There was an error while loading. Please reload this page.
Source Hash Extension for Source Maps - #85
Conversation
| also want to add them to the manifest. For this we could leverage the digest | ||
| header, with the small suboptimal situation that the HTTP digest spec uses | ||
| a base64 hash: |
There was a problem hiding this comment.
We should just embrace the reality that the headers have nothing to do with HTTP anymore (even though they originally were inspired by that).
This is all a bit bikesheddy, but we should strive for consistency here between the protocol, the sourcemap JSON, and these headers. We use a mix of different names and string/objects all over the place.
I believe we are currently limited by headers being a String->String mapping. But we could relax that as well if needed.
There was a problem hiding this comment.
I would honestly just move all this stuff out of headers and keep toplevel, but as it stands these are actually still http headers in the current implementation. It really just overlays the HTTP fetch.
This proposes and specifies support for source hashes in Sentry. This allows looking up source maps by the content hash of the transpiled / minified file. It leverages recent additions to Chrome and Edge (Caller.getScriptHash).
Relates to #81
Rendered RFC