how to bypass/buster a cached page programmatically?

Hi @alx359,
I didn’t get your question clearly. Can you explain your question with an example scenario? Cause once a page by CF, that request for that page is not even coming to your server and as soon as CF receives it, it sends the cached response without even sending that request to the server.

Hi Saumya,

Yes, I understand, thanks for your time. With client-side JS, it could sniff within the browser for IE, and if found reload the page to stick the booster’s suffix ?swcfpc=1 (and also set a cookie to further bypass, and for php processing). So the browser will produce a pass to hit the origin directly during such page reload, effectively bypassing the CF cache (hopefully).

I’m testing that idea right now with these pieces of code below, and at glance it seems to be working. But I’m certain you guys have a lot firmer grasp of the complexities at hand, and I’d prefer a more solid solution inside the CSPC framework if possible (with smart headers handling and stuff).

On scripts.js:

if( window.document.documentMode ) { // IE-only sniffer
	if( !Cookies.get('compat_ie') ) {
             Cookies.set('compat_ie', '1');
	     var href = new URL(window.location);
	     href.searchParams.set('swcfpc', '1');
	     history.pushState('data', '', href);
	}
}

On functions-compat-browser.php

if( isset( $_COOKIE['compat_ie'] ) ) {

        // add relevant capabilities to IE 
        // https://polyfill.io/v3/url-builder/
        wp_enqueue_script( 'polyfill-ie', ... etc.

Man I don’t use or work on IE. It’s a dead system. I would rather focus on bleeding edge than IE. But yes this IE hack should work. Cloudflare do not cache pages on custom cookies on then.

In still not understanding the goal on this ticket (sorry) it’s not a plugin issue. You can also maybe use the worker mode and then overwrite our default worker code by adding this logic of yours where you can check the request header to see if it’s IE and then bypass or something.

Of course, requirements and needs may vary. The more interesting part here I think is the proof of concept. HTTP_USER_AGENT handling, for example, isn’t available in CF free plans, nor in CSPC. But perhaps looking at the problem from the other (browser) side with some piece of JS code, could open possibilities to address this and other limitations more or less seamlessly, and still w/o paying CF any money.

Thanks anyway, and my apologies if you find the inquiry out of scope.

You can always take advantage of the worker for that. That’s why we made sure our worker code can be overwritten by people who wanna as site specific features to it.

Of course, but as tried to point out, narrowly focusing at the server side might not be the best approach for all situations. For example, in 4.3.7.4 it was removed the option “Bypass cache for the following user agents” because it slowed down the TTFB.