Add ability to translate header= into DNR responseHeaders condition

[Nexus-Gits]

Prerequisites

• This is NOT a YouTube, Facebook, Twitch or a shortener/hosting site report. These sites MUST be reported by clicking their respective links.
• I read and understand the policy about what is a valid filter issue.
• I verified that this issue is not a duplicate. (Search here to find out.)
• I did not remove any of the default filter lists, or I have verified that the issue was not caused by removing any of the default lists.
• I did not enable additional filter lists, or I have verified that the issue still occurs without enabling additional filter lists.
• I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
• I am not using uBlock Origin along with other content blockers.
• I have verified that the web browser's built-in content blocker/tracking protection, network wide/DNS blocking, or my VPN is not causing the issue.
• I have verified that other extensions are not causing the issue.
• If this is about a breakage or detection, I have verified that it is caused by uBlock Origin and isn't a site issue.
• I did not answer truthfully to ALL the above checkboxes.

URL(s) where the issue occurs.

https://yomovies.farm/

Description

Ads do not block by ublock origin lite on this site. when play video it pop up ads

Other extensions used

nothing.

Screenshot(s)

Screenshot(s)

Configuration

Details

[gorhill]

Possibly because the following filter can't be translated into a DNR rule for multiple reasons:

/^https?:\/\/(?:[a-z]{2}\.)?[0-9a-z]{5,16}\.[a-z]{3,7}\/[a-z](?=[a-z]{0,25}[0-9A-Z])[0-9a-zA-Z]{3,26}\/\d{4,5}(?:\?[_v]=\d+)?$/$script,3p,redirect-rule=noop.js,match-case

• Not a compatible regex (it uses lookaround assertion)
• redirect-rule can't be converted to DNR

[stephenhawk8054]

@gorhill Sorry, can MV3 use header now? I see the issue linked here is closed: w3c/webextensions#460

I think this issue can be solved by

*$script,3p,domain=minoplres.xyz,header=Access-Control-Allow-Headers:/megageocheckolololo/

if header is supported

[Celsius273]

response header matching was added in Chrome M128, so whenever that version lands?

[gorhill]

From RuleCondition documentation, responseHeaders support is pending. Also, as per HeaderInfo documentation, if the value to match is a regex, it will have to be translatable into simple pattern matching syntax, where only * and ? are supported.

Conversion of header= filters into DNR rules will have to wait for support to be official in stable release, and also to be sure that presence of responseHeaders rules does not break the extension on older versions of the browser not supporting the capability.

[danielhjacobs]

and also to be sure that presence of responseHeaders rules does not break the extension on older versions of the browser not supporting the capability

From my experience with ruffle-rs/ruffle#16694, this is doable with just a try/catch for adding the rule conditions on other browsers and older versions of Chrome that hadn't even begun implementing this rule condition, but on versions of Chrome that began implementing this feature behind a flag, adding the rule conditions does not throw but they take into account only their other conditions if the flag is not enabled, which may be undesirable. I had to use this code, suggested by Rob W from the Firefox team, to create a function to detect whether these conditions were really supported before registering them to work around that: w3c/webextensions#638 (comment). This is the Chrome bug indicating features developed behind a flag are not fully hidden behind the flag: https://issues.chromium.org/issues/347186592#comment9

It may be different for rules registered in the manifest.