[Mahn]

I've experienced this, and it's a major pain the ass if we are talking about not just testing but making it work for AdBlocker users. In our case once we had to resort to rewording the method name in our REST AJAX API endpoint so it wouldn't contain the word "counter" for it not to randomly fail for adblocker users. Why would an adblocker be so incredibly aggresive as to block random words from urls is beyond me.

[TeMPOraL]

> Why would an adblocker be so incredibly aggresive as to block random words from urls is beyond me.

Because advertisers are so aggressive about shoving shit in our direction. It's an arms race, and unfortunately we sometimes suffer from collateral damage.

[nsgi]

It makes sense if there's an image with the word "ad" in the url. Probably something similar to that.

[derefr]

A bit frightening to think about: SHA hexdigests (as used in, e.g., cache-busting) can contain the two-character-sequence "ad".

[userbinator]

I don't think adblockers will be so naive as to block anything that contains "ad" in the URL, but then again, there's a name for the bug caused by this particular type of matching:

https://en.wikipedia.org/wiki/Scunthorpe_problem

...so maybe some of them do have rather silly rulesets.

[derefr]

They don't usually match on something as silly as the regexp /ad/, no—but they _do_ frequently contain a regexp like /\bad\b/.

The problem being—and this is painful personal experience speaking—web frameworks will frequently also cater to directory inode limits of caching reverse-proxies in their cache-busting code by doing something like this:

    "/#{sha[0..1]}/#{sha}.#{orig_ext}"

...which means that, for a SHA that starts with "ad", you get an "/ad/" in the URL.