Support AdGuard's empty & mp4 static filter options
#701
Labels
Comments
|
There are currently 187 filters with |
|
So you will be discarding the filter as invalid ? |
|
WTH? AdGuard converts this filter to
|
|
Eh! That's not what their KB says. |
Of course not -- I wouldn't have opened an issue just for this trivial fix. It will be converted to an empty file -- zero bytes. I had to modify the redirect engine to accommodate the fact that To be clear, the list I pasted above was taken from NanoAdBlocker, it rejects filters with |
That's a Firefox issue, extensions should be exempt of CORS as dictated by the server. I don't know if there is an opened issue about this on bugzilla. |
|
I think it's a chrome issue too. |
|
I fixed the issue locally and it works fine with Chromium. |
I see few, maybe this: https://bugzilla.mozilla.org/show_bug.cgi?id=1419459 |
Interesting, so |
gorhill
added a commit
to gorhill/uBlock
that referenced
this issue
Aug 13, 2019
Related issue: - uBlockOrigin/uBlock-issues#701 The filter option `empty` is converted to `redirect=empty` by uBO internally; however unlike when the `redirect=` option is used expressly, the `empty` option does not require a resource type. When `empty` is used, only network requests which are meant to return a text response will be redirected to an empty response body by uBO -- so `empty` will not work for resources such as images, media, or other binary resources.
I suspect the |
|
Well it doesn't stop the incessant barrage of blocked network requests from appearing as it was expected of test url --
Status in network pane still remains blocked:other instead of returning 200 OK and the barrage continues in the logger
Nevermind, it's the same with Adguard's extension too, it doesn't follow the KB documentation and doesn't as work as expected. |
|
Hi all, Yeah, it works as expected with the standalone products indeed, but in the browser extensions, there's no alternative to implementing it as a redirect to data:base64. We are actually thinking about deprecating this in favor of $redirect in the future updates. The ETA is about 2-3 months. |
I think |
|
@gorhill well, it's up to you then. If you decide to support it, we won't remove it. Talking about shorthands, |
gorhill
added a commit
to gorhill/uBlock
that referenced
this issue
Aug 13, 2019
Related discussion: - uBlockOrigin/uBlock-issues#701 (comment) The `mp4` filter option will be converted to `redirect=noopmp4-1s` internally, and `media` type will be assumed.
empty static filter optionempty & mp4 static filter options
|
What to do? |
|
That's a browser's blocking notification as you're running into CORS, you will have to set Access-Control-Allow-Origin header by yourself to overide that. |
|
Hello @gorhill, don't know if it's really related but I'm trying to understand why one of our script is return a 307 when Ublock is activated wheread the other indicates only "blocked" Is this because the old one is in a way "known" by Ublock? Thanks a lot in advance, Maxime. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related discussion: https://www.reddit.com/r/uBlockOrigin/comments/coh3aa/why_translategooglecom_is_block_so_many_requests/
The text was updated successfully, but these errors were encountered: