Is this all in the same configuration? Or duing a config reload? On Fri, Nov 13, 2020 at 1:39 PM Olsen, Brian <brian_ols...@comcast.com.invalid> 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 it should act as though a new rule came in. > > On 11/13/20, 11:59 AM, "Olsen, Brian" <brian_ols...@comcast.com.INVALID> > wrote: > > 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" > <sudheervinuko...@yahoo.com.INVALID> > wrote: > > 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 < > brian_ols...@comcast.com.invalid> wrote: > > 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) is loaded any attempts to reissue that rule again > is ignored. > > To work better with this self service case I’d like to propose > that when regex revalidate sees a new rule with a changed expiration that > this new rule’s expiration time becomes the new expiration time and the > activation time is reset to this new load time. > > I think it would be best to add some parameter to regex_revalidate > so that it works in this way. > > Any comments? > > Thanks! > > >
