Issue metadata
Sign in to add a comment
|
chrome.webRequest does not intercept requests for external source maps
Reported by
unknowns...@gmail.com,
Jan 7
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Create an extension with "webRequest" and "*://*/*" host permissions. 2. Add a listener to the "chrome.webRequest.onBeforeRequest" in extension's code and console.log() requests data. 3. Open a webapp that has external sourcemaps 4. Open extension's background page and inspect the log there What is the expected behavior? You will see all request including the request for the sourcemap file to appear. e.g. localhost/main.bundle.js and localhost/main.bundle.js.map. What went wrong? The requests for the source map file are not being intercepted by the chrome.webRequest api. So, the request for source maps does not appear and cannot be modified. It's almost as if those fetches are being hidden by chrome even from the chrome extensions. This is an issue for our company because we authenticate all our requests using a chrome extension to add special headers to each request. Because the sourcemap request isn't being intercepted the headers aren't being added and then they are rejected by our backend, so we can't get sourcemaps to work. Did this work before? Yes Chrome 68 Does this work in other browsers? N/A Chrome version: 71.0.3578.98 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: I am not sure exactly what changed with the way requests are handled for source maps, but I wonder if this might affect other types of requests that are handled by devTools.
,
Jan 8
Thanks for filing the issue... @reporter: Could you please provide a sample extension or a file that reproduces the issue so that it would be really helpful for further triaging of the issue.
,
Jan 8
Hey @swarnasree Thanks for the quick reply. A quick google search and I found this chrome extension https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj What you can try is to use that chrome extension with something like Fiddler watching the network traffic Set a dummy header like `X-Test-Header` Then load up an http webpage with sourcemaps or run something locally Then in fiddler you can see the network traffic with the dummy request header. For the network request for the `/` you will see the dummy the request header For the network request for the source map `/main.js.map` the dummy request header will not be there.
,
Jan 8
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 8
,
Jan 9
@reporter: As mentioned in comment#0 installed the extension, could you please provide URL with Fiddler watching the network traffic and if possible could you please provide a screencast/screenshot of the issue so that it would be really helpful in further triaging of the issue. Attached screenshot for reference. Thanks.!
,
Jan 9
Step 1. Add X-Test-Header (See attached Screenshot) Step 2. Refresh page and open fiddler Step 3. Look at request for app.[hash].js (See attached screenshot. I highlighted where the header appeared) Step 4. Look at the request for app.[hash].js.map (see attached screenshot) This is easier to see with HTTP requests as HTTPS requests are harder to decrypt with fiddler and add an extra layer of complexity. I just git cloned this repo https://github.com/wbkd/webpack-starter And used a live reload server for testing purposes. It should work for you as well if you want to test locally.
,
Jan 9
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 9
Another thing you can do is Step 1. Open the background.js on modheader and add a breakpoint at the listener for the webRequest onBeforeSendeHeaders. (See attached) Step 2. Refresh the starter app and you will see the break point stopped for index.html bundle.css app.[hash].js but it will never break for app.[hash].js.map (see attached)
,
Jan 10
Tried testing the issue on the reported chrome version using Windows 7 by following below steps. Steps: ===== 1.Launched chrome. 2.Downloaded file from "https://github.com/wbkd/webpack-starter". 3.Installed the extension "https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj". 4.Added the "X-Test-Header". 5.Opened the "index.html" page. 6.Opened Devtools->Network and refreshed the page. 7.Unable to see any "app.[hash].js" requests. Attached screencast for reference. @reporter: Could you please review attached screencast and let us know if anything is missed from our end. Thanks.!
,
Jan 10
It seems like you missed the instructions on the webpack starter page. You have to run `npm install` `npm start` Right now you are just opening up the index.html not the full web application. In addition, you won't be able to see the `app.[hash].js.map` request in the network tab as per this feature enhancement https://bugs.chromium.org/p/chromium/issues/detail?id=362913#c11 That is why you would need something like fiddler or wireshark to sniff the request to see the actual request. I don't know if you have some other internal tools that might provide better network inspection.
,
Jan 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 11
Tried to reproduce the issue on reported chrome version #71.0.3578.98 using Windows 10 by following below steps. Steps: ===== 1.Launched chrome. 2.Downloaded file from "https://github.com/wbkd/webpack-starter". 3.Opened terminal and started npm by executing "npm install" and "npm start". 4.Installed the extension "https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj". 5.Refreshed the page and opened the fiddler. 6.Tried searching "app.[hash].js" request, found "app.js". 7.Opened "Header" and found "No response Body". Attaching screencast for reference. As the issue is not getting reproduced from TE-end, hence adding "TE-NeedsTriageHelp" label and requesting dev team to look into the issue and help in further triaging. Thanks.!
,
Jan 11
That's weird that the dev server isn't showing the map. Maybe because it only loads sourcemaps on production.
Sorry, but can you try one more thing.
In the webpack-starter folder add an `index.js` file (see attached)
Copy and paste the following into that file (ignore the ```) just everything between those
```
const express = require('express');
const app = express();
const port = 8080;
app.use(express.static('build'));
app.listen(port, () => console.log(`Example app listening on port ${port}!`))
```
Then run in your terminal
`npm build`
`node index.js`
Then go to localhost:8080 and do the same steps as you did as above and you should see the files
,
Jan 16
(6 days ago)
Hello @swarnasree.mukkala@chromium.org Is there any update on this? -Michael
,
Jan 17
(5 days ago)
@battre: Could you please have a look into the issue and help in further triaging of it. Tentatively adding Platform>Extensions>API. Thanks.!
,
Jan 18
(4 days ago)
Hello all, I am experiencing same behavior. We use a custom header to differentiate our environments and we noticed that all "js.map" are missing this header so they are downloaded from production (there it is not necessary this header). The last version where it worked as expected is 69.0.3497.100. Thanks |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Jan 8