Opened on 08/03/2016 at 02:35:31 PM

Closed on 08/29/2019 at 05:43:52 PM

#4302 closed defect (rejected)

^ doesn't match URL with a dot after domain name

Reported by: Lain_13 Assignee:
Priority: Unknown Milestone:
Module: Core Keywords: closed-in-favor-of-gitlab
Cc: kzar, sebastian, mapx, fanboy, segz Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by mjethani)


Google Chrome 52.0.2743.82 m
Adblock Plus development build

How to reproduce

  1. Create test page which loads resource like this:

  1. Add filter:^$script

Observed behaviour

Resource is not blocked because ^ doesn't match the dot at the end.

Expected behaviour

should match "./" combo to avoid creating duplicate filters like:^$script

Attachments (0)

Change History (21)

comment:1 Changed on 08/03/2016 at 02:37:36 PM by Lain_13

Could someone please fix ^? I haven't noticed it's effect before it were too late and now I can't edit.

comment:2 Changed on 08/03/2016 at 05:17:02 PM by mapx

  • Description modified (diff)

comment:3 Changed on 08/03/2016 at 05:25:17 PM by mapx

  • Description modified (diff)

comment:4 Changed on 08/03/2016 at 05:26:06 PM by mapx

  • Description modified (diff)

comment:5 Changed on 08/03/2016 at 05:26:26 PM by Lain_13

Also, I've missed $ between ^ and script

comment:6 Changed on 08/03/2016 at 06:16:53 PM by mapx

  • Description modified (diff)

comment:7 Changed on 08/03/2016 at 07:55:35 PM by Lain_13

Live example here:
Look for the script:

comment:8 Changed on 08/04/2016 at 06:29:41 AM by mapx

  • Cc kzar sebastian mapx added

comment:9 Changed on 08/05/2016 at 01:19:32 PM by kzar

  • Cc trev added
  • Component changed from Unknown to Core

(Since this behaviour is consistent with the Firefox extension I guess this is a core issue.)

comment:10 Changed on 08/05/2016 at 01:57:47 PM by trev

Thing is: and aren't the same thing. Technically, it is really two different host names and the content isn't required to be identical. So I'd argue that the current behavior is correct - if both and need to be covered then two separate filters are necessary. Having ^ accept both would be unexpected behavior...

comment:11 Changed on 08/05/2016 at 02:02:36 PM by Lain_13

I'm not so sure:
Is there an example when content with and without dot is different? As I understand version with the dot is just a FQDN and without one - relatively qualified, but dot added internally later on anyway.

Last edited on 08/05/2016 at 02:06:48 PM by Lain_13

comment:12 Changed on 08/05/2016 at 02:16:52 PM by trev

As far as DNS is concerned they are the same. Web servers and browsers treat them as different entities however.

comment:13 Changed on 08/05/2016 at 02:23:18 PM by Lain_13

Well, this trailing dot is mostly used to avoid blocking and I haven't seen even one case yet when it were used for something different. So, I think it shouldn't be a big deal to add two filters (|| and || to avoid blocking of the || if we ever encounter a situation when they should be treated separately.

Also, it's not possible to register a domain name with the dot in the end, same as an existing one. So, anyway that dot will be processed by the same server and since we are mostly using ||^ syntax to block ad servers completely then why should we intentionally leave them a way to serve their content only to block it later on with an extra filter?

Last edited on 08/05/2016 at 02:29:45 PM by Lain_13

comment:14 Changed on 09/12/2016 at 04:02:50 PM by mapx

  • Cc fanboy added

comment:15 Changed on 12/21/2017 at 11:27:49 AM by fhd

  • Cc trev removed

comment:16 Changed on 01/04/2018 at 01:22:13 PM by sergz

  • Cc segz added

comment:17 Changed on 03/17/2019 at 10:06:03 AM by mjethani

This was fixed in #6690. I am closing this.

comment:18 Changed on 03/17/2019 at 10:06:17 AM by mjethani

  • Resolution set to duplicate
  • Status changed from new to closed

comment:19 Changed on 03/17/2019 at 10:06:42 AM by mjethani

  • Description modified (diff)

comment:20 Changed on 03/17/2019 at 10:34:39 AM by mjethani

  • Description modified (diff)
  • Resolution duplicate deleted
  • Status changed from closed to reopened

Sorry, I made a mistake. #6690 is about the hostname of the document making the request, not the hostname part of the request URL. This indeed does not work.

comment:21 Changed on 08/29/2019 at 05:43:52 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from reopened to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.