@Khady unfortunately, that's a limitation of request interception for now.

@aslushnikov Do you mean it is a limitation of how request interception works in chrome or a limitation in puppeteer?

I'm not sure of what is the original issue. If it is that sometimes a request receives a response from cache and doesn't go through the request interception system, I'm ready to live with this "weird" behavior. I prefer it to the new behavior (which means I loose all my cache IIUC). Because in my case, a response that has been cached will always correspond to a request that would not be blocked or affected by the request interception.

I render a big number of pages using puppeteer and cache saves some network and time. I would be happy with a new parameter to setRequestInterception to turn off the line this._client.send('Network.setCacheDisabled', {cacheDisabled: enabled}), for example. Or to add a new method to decide myself of the value I want for setCacheDisabled. I don't mind setting setCacheDisabled to false myself explicitely, but AFAIK puppeteer doesn't allow me to use the devtools protocol on my side. I can provide a PR if necessary.

Do you mean it is a limitation of how request interception works in chrome or a limitation in puppeteer?

@Khady that's a limitation in chrome, interception won't work as it should with caching enabled. This limitation might go away some time in future: there's an on-going refactoring effort in chromium network stack that should help us here.

Agree with @Khady - I am also prepared to live with the "weird" behavior.

@aslushnikov or anyone else from the Puppeteer team: what is the status please on enabling caching & request interception at the same time?

@Khady @emiliavanderwerf See #6996, #7038, and #7060,