Strange behavior `no-xhr-if` when specifying headers

[dimisa-RUAdList]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

If add any arbitrary header value to the rule, then all requests of this type are blocked.

A specific URL where the issue occurs.

https://pikabu.ru/

Steps to Reproduce

Add: pikabu.ru##+js(no-xhr-if, headers:blabla)

Expected behavior

There are no such values in the headers, so the rule shouldn't do anything.

Actual behavior

All xhr requests are blocked.

This issue was also discussed here: uBlockOrigin/uAssets@ca9898d#commitcomment-129975750

uBO version

uBlock Origin 1.52.3b9

Browser name and version

Firefox 118.0.2

Operating System and version

Windows 11

[gorhill]

headers is not an argument to XMLHttpRequest.open(), it can't be used as a matching target in no-xhr-if scriptlet.

[dimisa-RUAdList]

Oh, I'm sorry. Obviously, I was misled.

[gorhill]

If you have actual cases where this would be useful, I could look to extend the scriptlet through XMLHttpRequest.setRequestHeader(), but if not I rather not spend time on this.

[dimisa-RUAdList]

Sometimes network requests are so confusing that it becomes difficult to distinguish between advertising and functional ones. But their headers may differ. In the case of Adblock Plus, I use option $header.

Here is one such example: abp-filters/abp-filters-anti-cv#699 (comment)

And here are other similar use cases: https://github.com/abp-filters/abp-filters-anti-cv/issues?q=header%3D

[gorhill]

In the case of Adblock Plus, I use option $header.

Unfortunately not compatible with MV3.

Here is one such example: abp-filters/abp-filters-anti-cv#699 (comment)
...
Please add (for Firefox): ||cq.ru^$xmlhttprequest,header=cq-cache-bypassed

I am not able to reproduce a blocked network request through a header filter with ABP. Is this on a specific webpage?

[dimisa-RUAdList]

Screenshot(s)

[gorhill]

Ok, so this about response headers, not request headers. This mean the request is made to the server, but matched and blocked once the response headers arrive. Now if I use uBO + RUAdList instead, I see you are blocking the request by pattern, which is more efficient, so why go with the header solution for ABP?

[dimisa-RUAdList]

The fact is that the path of the advertising network request https://cq.ru/cq67er changes periodically. The frequency of rotation is from once a week to several times a day.

Therefore, as an effective rule for uBlock Origin (Google Chrome), I use:
cq.ru##+js(addEventListener-defuser, DOMContentLoaded, banners)

For Adblock Plus (Google Chrome) this is: cq.ru#$#prevent-listener DOMContentLoaded 'banners'

However, in Firefox these rules are unstable, so a rule has been added for uBlock Origin:
cq.ru##^script:has-text(window.initBanners)

And for Adblock Plus: ||cq.ru^$xmlhttprequest,header=cq-cache-bypassed

[uBlock-user]

@dimisa-RUAdList Have you tried uBO's $header network filter ?

[dimisa-RUAdList]

@uBlock-user
The rule ||cq.ru^$xmlhttprequest,header=cq-cache-bypassed works fine, but by default this option (filterOnHeaders) is disabled, so adding it to RU AdList is useless.

[gorhill]

header= available in 1.52.3b10 as a non-experimental option: gorhill/uBlock@c96a673338