Add ability to translate `header=` into DNR `responseHeaders` condition

Nexus-Gits commented 3 months ago

Prerequisites

[X] This is NOT a YouTube, Facebook, Twitch or a shortener/hosting site report. These sites MUST be reported by clicking their respective links.
[X] I read and understand the policy about what is a valid filter issue.
[X] I verified that this issue is not a duplicate. (Search here to find out.)
[X] 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.
[X] I did not enable additional filter lists, or I have verified that the issue still occurs without enabling additional filter lists.
[X] I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
[X] I am not using uBlock Origin along with other content blockers.
[X] 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.
[X] I have verified that other extensions are not causing the issue.
[X] If this is about a breakage or detection, I have verified that it is caused by uBlock Origin and isn't a site issue.
[X] 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)

Configuration

Details

```yaml ```

gorhill commented 3 months ago

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 commented 3 months ago

@gorhill Sorry, can MV3 use header now? I see the issue linked here is closed: https://github.com/w3c/webextensions/issues/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 commented 3 months ago

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

gorhill commented 3 months ago

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 commented 2 months ago

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 https://github.com/ruffle-rs/ruffle/pull/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: https://github.com/w3c/webextensions/issues/638#issuecomment-2181124486. 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.

gorhill commented 1 month ago

It would help if uBO's header= syntax matched the DNR's HeaderInfo's syntax:

If specified, this condition matches if the header's value matches at least one pattern in this list. This supports case-insensitive header value matching plus the following constructs: * : Matches any number of characters. ? : Matches zero or one character(s). * and ? can be escaped with a backslash, e.g. \* and \?

I think uBO could supports the DNR's pattern matching syntax. uBO would still support the regex syntax, which would need to be dropped from the conversion, but plain or pattern-matching syntax would be translated to DNR rule with no special processing.

stephenhawk8054 commented 3 days ago

Reference from MDN:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest/HeaderInfo

Looks like it's available for chromium now.

Oh sorry, there's reference link from chromium above already.

uBlockOrigin / uBOL-home