[DNR] Redirect rule does not allow applying other redirect rules to the resulting request

[ameshkov]

Problem

The current implementation in both Chrome and FF does not allow "chaining" redirect URLs.

Here's the problem:

1. Let's have a request to https://example.org/?utm_campaign=foo&fb_ref=bar
2. And have two different rules, one that removes utm_campaign parameter and the other one that removes fb_ref.
3. The first rule will be applied and it will result in a new request to https://example.org/?fb_ref=bar, however other redirect rules will not be applied to that new request.

The problems of this approach are:

1. Inconsistency. Other DNR rules can be applied to the new request, the exception is only made for redirect.

2. Inability to target specific URL parameters. For instance, in AdGuard URL Tracking filter some rules are generic and we can combine them into a single DNR rule, but there are some rules specific for a given website.

   For instance, there's a rule for bloomberg.com: ||bloomberg.com^$removeparam=in_source. With the current implementation we'll need to merge generic rules with every "specific" rule to cover all parameters. But there still will be edge cases like this where merging would be more problematic:

   ||donation.yahoo.co.jp^$removeparam=cpt_n
   ||yahoo.co.jp^$removeparam=ikCo

Proposal

The proposal is to allow applying other redirect rules to a request even if this request is a result of applying a different redirect rule.

[xeenon]

Safari also does not allow chaining redirects today.

[Rob--W]

The above description is not entirely accurate (but the issue is valid). Redirects can be chained, provided that the redirect is actually a different URL.

DNR rules are applied to resulting redirect (at the start of the next request), at least in Firefox and Chrome.

To prevent redirect loops, a redirect to the same URL is ignored. If it were not to be ignored, the evaluation of all DNR rules would yield exactly the same action because the conditions of a request is completely unchanged.

If you want rules to chain, then you need to order your rules such that no-op redirects aren't possible. E.g. by including the query param that you want to remove in the urlFilter. ||yahoo.co.jp/*?*ikCo^ for example. This work-around isn't perfect, because it would also match if the "query parameter" is part of a non-query param. An alternative is to specify multiple rules, e.g. ||yahoo.co.jp/*?ikCo= + ||yahoo.co.jp/*?*&ikCo=, but that consumes another rule from the quota.

But even with that work-around, another problem with that is that the number of redirects in a chain is limited. So the best you can do with the current constraints is really to merge the generic rules in the more specific rules, and let these specific rules have a higher priority.

[Rob--W]

I'm supportive on Firefox's behalf of supporting a better way of removing parameters, e.g. by applying all same-priority queryTransform.removeParams rules at once (instead of just the first).

Safari and Chrome needs to check with their experts before deciding what they'd like.

[ameshkov]

The issue was discussed during the WECG in-person meeting.

The suggested way forward is applying all same-priority “redirect” rules at once instead of just the first.

Other precautions should stay in place, i.e.:

1. To prevent redirect loops, a redirect to the same URL is ignored.
2. The number of redirects in a chain stays limited.