chrome-remote-interface
chrome-remote-interface copied to clipboard
Message regarding 'using unsafe HTTP verb GET' for new tab
Environment
| Component | Version |
|---|---|
| Node.js | 16.16.0 |
| Client (Chrome/Chromium/...) | 103.0.5060.134 (64-bit) |
| OS running Node.js | Windows 10 |
| OS running the client | Windows 10 |
| chrome-remote-interface | 0.31.3 |
Is the client running in a container? No
Description
When using chrome-remote-interface with Chrome headless to create a new target/tab and load a URL, a warning message is shown by Chrome/Chromium:
DevTools listening on ws://127.0.0.1:9222/devtools/browser/79f696b9-e333-431c-b81d-a9121af0c4d6
[0728/194459.111:ERROR:devtools_http_handler.cc(636)] Using unsafe HTTP verb GET to invoke /json/new.
This action will stop supporting GET and POST verbs in future versions.
Can this message be ignored, or is there a solution or workaround available for it? I've already updated nodejs, npm, Chrome, and chrome-remote-interface lib to their latest stable versions.
Example
const CDP = require('chrome-remote-interface');
async function example() {
let client, target;
try {
// connect to endpoint
target = await CDP.New();
client = await CDP({ target });
// extract domains
const {Network, Page} = client;
// setup handlers
Network.requestWillBeSent((params) => {
console.log(params.request.url);
});
Network.responseReceived(async ({requestId, response}) => {
const {body, base64Encoded} = await Network.getResponseBody({requestId});
console.log(body, base64Encoded);
});
// enable events then start!
await Network.enable();
await Page.enable();
await Page.navigate({url: 'https://example.com'});
await Page.loadEventFired();
} catch (err) {
console.error(err);
} finally {
if (target) {
//await client.close();
await CDP.Close({id: target.id});
}
}
}
example();
You can ignore it for now, a fix will arrive shortly. Thanks for letting me know.
Too bad the obvious fix (using PUT) would break other implementations, e.g., Firefox...
Will HEAD or PATCH work?
I'm not even sure why the Chrome/Chromium teams are now considering GET and POST unsafe for invoking devtools endpoints, that too without any alternative provided? Doesn't Puppeteer use chrome-remote-interface and/or devtools protocol under the hood as well? How are they going to address this issue?
Will
HEADorPATCHwork?
Nope, at this point each implementation might decide to accept/refuse certain methods. So a more general solution, where the method to be used is passed in as an option, might be needed.
I'm not even sure why the Chrome/Chromium teams are now considering
GETandPOSTunsafe for invoking devtools endpoints, that too without any alternative provided?
More info here.
It doesn't make any sense IMHO, I feel this is an attempt to mitigate some CSRF but one could easily bypass this restriction by hosting a page with:
<script>
fetch('http://127.0.0.1:9222/json/new', {method: 'PUT'});
</script>
Doesn't Puppeteer use
chrome-remote-interfaceand/or devtools protocol under the hood as well?
Puppeteer doesn't use chrome-remote-interface, rather it interacts with the protocol directly.
How are they going to address this issue?
They are just using PUT, see this PR.
Maybe just have conditional method in code for now: PUT for Chrome (and Chromium-based Edge?), GET for others.
I am using a package which is dependent on chrome-remote-interface - html-pdf-chrome. This just started failing for me, I have Chrome 108.0.5359.124, MacOS: 13.2 Beta (22D5027d), Apple M1 Pro.
I am assuming this warning is now classified as an error in the newest version to which I auto updated to since the last time I ran the html-pdf-chrome package. Was working 1/2 months ago.
Some information I have found on the issue:
- A mini post describing the issue and linking to chromium change that introduced this warning originally https://danielcompton.net/snippets/chrome-devtools-unsafe-http-verb
How I worked around it: Installed older Chromium instead of running stock Google Chrome on Mac
- A guide how to get an older Chromium browser version before the warning was introduced (I tested with 102, here is the link for mac https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/992796/, it works fine for me, I am assuming even a more newer version would work). https://www.chromium.org/getting-involved/download-chromium/#downloading-old-builds-of-chrome-chromium
- Used this to find the chromium release version number https://chromiumdash.appspot.com/releases?platform=Mac
So now only the New method will use PUT, and since this method is only supported in Chrome (and Opera? Cannot try right now...) it should break nothing.