Rules from a previous version of the config file are not a problem, it is
duplicate lines in the config file that are, correct? I wonder how you even
detect that, other than literal string compares. It does make a bit of an
outlier, since it's last match instead of the first match for everything
el
This would be during a config reload. It's not uncommon to end up with the
same regex showing up multiple times in that file with different expiration
times. The error made comes from choosing too long a TTL for the revalidation
rule.
On 11/17/20, 7:40 AM, "Alan Carroll"
wrote:
Is thi
Is this all in the same configuration? Or duing a config reload?
On Fri, Nov 13, 2020 at 1:39 PM Olsen, Brian
wrote:
> Never mind that's too hard to keep track of. The idea here is that if a
> new regex_revalidate rule comes in with the same regex as an active but a
> different expiration time
Never mind that's too hard to keep track of. The idea here is that if a new
regex_revalidate rule comes in with the same regex as an active but a different
expiration time it should act as though a new rule came in.
On 11/13/20, 11:59 AM, "Olsen, Brian" wrote:
For safety's sake it might
For safety's sake it might be best to take the rule expiration that's furthest
away (including any already loaded rules) and reset the activation/epoch.
On 11/13/20, 10:03 AM, "Sudheer Vinukonda"
wrote:
Sounds reasonable to me.
Unless, it breaks some backward compatibility that can't
Sounds reasonable to me.
Unless, it breaks some backward compatibility that can't be worked around, it
feels that this behavior can be made the default (without any need of a config
even).
Thanks!
Sudheer
On Friday, November 13, 2020, 08:38:43 AM PST, Olsen, Brian
wrote:
Through traff
Through traffic control we have the limited ability for CDN customers to add
revalidation requests. Unfortunately there are times when assets need to be
revalidated multiple times due to whatever reason.
The way regex_revalidate works now it is first rule wins, meaning that once a
rule (regex)
