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

[Lain_13]

Environment

Google Chrome 52.0.2743.82 m
Adblock Plus development build 1.12.1.1627

How to reproduce

1. Create test page which loads resource like this:

​http://gogame3.game-rust.ru./55t81h7fiaj7surb1af3va6bkgpocrw4050uc2xf0h0c507pscxrkm23u0qo?3ubo8ums=ea8c

2. Add filter:

   .game-rust.ru^$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:}

.game-rust.ru.^$script

[Lain_13]

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

[Lain_13]

Also, I've missed $ between ^ and script

[Lain_13]

Live example here: ​http://kinoprofi.net/
Look for the script: ​http://psma01.com./js/sys.js

[kzar]

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

[trev]

Thing is: gogame3.game-rust.ru and gogame3.game-rust.ru. 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 gogame3.game-rust.ru and gogame3.game-rust.ru. need to be covered then two separate filters are necessary. Having ^ accept both would be unexpected behavior...

[Lain_13]

I'm not so sure: ​http://www.dns-sd.org/trailingdotsindomainnames.html
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.

[trev]

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

[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 (||domain.name: and ||doman.name/) to avoid blocking of the ||domain.name./ 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 ||domain.name^ 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?

[mjethani]

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

[mjethani]

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.

[sebastian]

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