Closed p4fg closed 4 years ago
Hi, I'm glad that you can find it useful!
Yes the problem is that Chrome considers (top-level at least) 204 resources as failed even though are fully processed. Try this:
const CDP = require('chrome-remote-interface');
async function example() {
try {
const client = await CDP();
const {Network, Page} = client;
client.on('event', ({method, params}) => {
console.log(method, params);
});
await Network.enable();
await Page.navigate({url: 'https://poc.shellcode.se/204.php'});
} catch (err) {
console.error(err);
}
}
example();
Then:
$ node 204.js
[...]
Network.loadingFailed { requestId: '40AA6A899C7C6E74255E4590CAD1DC72',
timestamp: 3816.6678,
type: 'Document',
errorText: 'net::ERR_ABORTED',
canceled: true }
I'm not sure if I should add an exception to that. What's your use case in detail?
My current use-case is spidering and analysis. It would be beneficial to know when a retry is warranted (might give a result) or if the retry will give the same result.
Is there any remote version of the network-request/response tab in the dev-tools? In that tab it is possible to distinguish errors from 204-responses (see attached image)
I don't really see the problem though, you only have that behavior for top-level page loads, but if a webpage contains resources that yield 204 everything works fine. For example:
<img src="https://poc.shellcode.se/" />
<img src="https://poc.shellcode.se/204.php" />
$ gron out.har | grep 'request.url \|response.status '
json.log.entries[0].request.url = "http://127.0.0.1:8080/index-204.html";
json.log.entries[0].response.status = 200;
json.log.entries[1].request.url = "https://poc.shellcode.se/";
json.log.entries[1].response.status = 200;
json.log.entries[2].request.url = "https://poc.shellcode.se/204.php";
json.log.entries[2].response.status = 204;
If you are writing a spider you will want to visit all links on a page, hence my problem.
I don't know, I'm uncomfortable in adding the exception: if failed BUT 204 then not failed. The way Chrome handles such pages (top-level page loads only) is to emit a Network.loadingFailed
with errorText
set to net::ERR_ABORTED
, so I think I should honour that.
Back to your problem, you can treat net::ERR_ABORTED
as an absolute failure, e.g., not a timeout or something that you want to retry.
Hi, thanks for a really well written library! I got an issue with pages returning HTTP 204 (No content).
Pages returning 204 are somehow counted as failing and the onFail-handler is called.
To reproduce:
Observed behaviour:
Expected behaviour: