fix(interception): Disable newtork caching when intercepting

[aslushnikov]

Request interception might not work properly if caching is enabled.

[dgozman]

Wonderful change!

[JoelEinbinder]

Lgtm

…

On Tue, Oct 24, 2017 at 3:14 PM dgozman ***@***.***> wrote: ***@***.**** approved this pull request. Wonderful change! — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#1154 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEaPaeIEn-i6es3MKjBCdT__kjYh3Wbwks5svmE5gaJpZM4QFJPE> .

[Khady]

Could we have a way to activate caching even if intercepting is activated? I don't want to loose all the cache to block or respond in a custom way to a few requests.

[aslushnikov]

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

[Khady]

@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.

[aslushnikov]

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.

[emiliavanderwerf]

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?

[Androbin]

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