Browser caching works with interception enabled, but the documentation says it shouldn't

[bluepeter]

The documentation states:

NOTE Enabling request interception disables page caching.

However, this doesn't appear to actually be the case. I await chromePage.setRequestInterception(true) and log out cache activity:

    chromePage.on("response", resp => {
      console.log(
        "Received: " +
          resp.fromCache() +
          " " +
          resp.status() +
          " " +
          resp.url()
      );
    });

When I crawl the same page twice, my log reveals that cache is being used on the 2nd load for some resources (and for whom I res.continue() with no mutation), despite interception enabled:

Received: true 200 https://pro.fontawesome.com/releases/v5.1.0/css/all.css
Received: true 200 https://fonts.googleapis.com/css?family=Roboto:300,400,500

Am I mis-interpreting things, or should the documentation be updated to reflect that page caching will work w/ interception?

[gombosg]

I can attest this!
Because the docs said that they don't work together, I spent 2 days to set up SSL bumping with a proxy etc. just to find this bug report, try and... yes, it's working!

I can have my cake and eat it too, turning on caching and request interception, both of which saves me a ton of bandwidth for crawling. (Caching JS files and disabling images and tracking crap.)

[gombosg]

Similar stuff: #2905, pr#1154

Maybe the documentation could elaborate how the system is working?

[swang2019]

WOOOOOOOOW, just found this, since I want both caching and crap blocking..

I will do a test, and save me a day if it works.

[swang2019]

Unfortunately, on my test, it's not working, (cached is disabled when setRequestInterception (true) )

[JohnBruce]

On 1.12.2 setting request interception enabled does indeed disable caching for me. (unfortunately I don't really want it to 😢 )

[jadell]

Would it be possible for #2905 be re-opened, so that we can have both caching and request interception?

[stale]

We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days.

[stale]

We are closing this issue. If the issue still persists in the latest version of Puppeteer, please reopen the issue and update the description. We will try our best to accomodate it!