Currently, method: Post is used and this filter is thus invalidated. Just a head up for anyone who cares about this specific site.

does this help ?

skk.moe##+js(no-fetch-if, body:/[\w\W]{700}/)

@mapx- I am not entirely sure what this filter is based on (a key in the body?). I would like to find a way to stop a kind (verb) of request (reading a blog imo doesn't need to POST anything in the background), and right now I can't find any effective way to achieve this goal.

Test for breakage

skk.moe##+js(aopr, btoa)

or

skk.moe##+js(aost, Number.isNaN)

or

skk.moe##+js(aost, fetch, /A\s.*/)

I see no POST anymore.

skk.moe##+js(aopr, btoa) this one seems work well as only tracking used it.

@mapx-

And you are just breaking following page:

• https://hv-monster.skk.moe/ (Charts stop working)
• https://lab.skk.moe/hentaiverse-expgraph

Those pages are using ECharts library which uses window.btoa.

I believe the root cause is because no-fetch-if does not support case insensitive (require extra params if build regex from string), while in fetch() you could pass PoSt as method while still have correct behavior but bypass the filter.

@gorhill this needs to be addressed...

##+js(no-fetch-if, method:/post/i) will work.

##+js(no-fetch-if, method:/post/i) will work.

It doesn't.

What filter doesn't work where?

@gorhill Add blog.skk.moe##+js(no-fetch-if, url:post) and/or blog.skk.moe##+js(no-fetch-if, method:/post/i) and browse to blog.skk.moe, observe that fetch request of method:post is fired and with url having post string in it despite having the filter/s to defuse both. Both filters get bypassed.

The site uses an object with non-enumerable properties as the fetch's options argument, so the scriptlet can't "see" these options. Maybe one way to counter this is to at least explicitly lookup common properties instead of just using Object.assign.

The site uses an object with non-enumerable properties as the fetch's options argument, so the scriptlet can't "see" these options. Maybe one way to counter this is to at least explicitly lookup common properties instead of just using Object.assign.

Let's leveling the playing field a little bit: one of the proper ways to do this is to use Object.prototype.hasOwnProperty.call to look up the property first, then explicitly reading the value, which is what AdGuard's scriptlet does. Object.getOwnPropertyNames could also be a good alternative if you wish to stay with for ... in ....

1.67.1b5 This version broke the test. https://www.cloudflare.com/ru-ru/ssl/encrypted-sni/#results