chrome-remote-interface icon indicating copy to clipboard operation
chrome-remote-interface copied to clipboard

Message regarding 'using unsafe HTTP verb GET' for new tab

Open VoidMonk opened this issue 3 years ago • 5 comments

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();

VoidMonk avatar Jul 28 '22 09:07 VoidMonk

You can ignore it for now, a fix will arrive shortly. Thanks for letting me know.

cyrus-and avatar Jul 28 '22 10:07 cyrus-and

Too bad the obvious fix (using PUT) would break other implementations, e.g., Firefox...

cyrus-and avatar Jul 28 '22 11:07 cyrus-and

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?

VoidMonk avatar Jul 28 '22 23:07 VoidMonk

Will HEAD or PATCH work?

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 GET and POST unsafe 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-interface and/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.

cyrus-and avatar Jul 29 '22 08:07 cyrus-and

Maybe just have conditional method in code for now: PUT for Chrome (and Chromium-based Edge?), GET for others.

VoidMonk avatar Jul 30 '22 01:07 VoidMonk

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

bra1nDump avatar Jan 10 '23 20:01 bra1nDump

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.

cyrus-and avatar Jan 12 '23 16:01 cyrus-and