[PATCH 1/2] storage: Add "filtered" option, to store based on the filter's decision
Julien ÉLIE
julien at trigofacile.com
Fri Jan 26 21:33:30 UTC 2024
Adding to my previous message:
>> @@ -643,6 +653,7 @@ SMgetsub(const ARTHANDLE article)
>> && (!sub->maxsize || (article.len <= sub->maxsize))
>> && (!sub->minexpire || article.expires >= sub->minexpire)
>> && (!sub->maxexpire || (article.expires <= sub->maxexpire))
>> + && (sub->filtered == article.filtered)
>> && MatchGroups(article.groups, article.groupslen,
>> sub->pattern,
>> sub->exactmatch)) {
>> if (InitMethod(typetoindex[sub->type]))
>
> When dontrejectfiltered is set in inn.conf, I am under the impression
> that the above additional condition will break storage for people who do
> not use the filtered parameter.
> If I do not have the new filtered parameter set on any storage class,
> then filtered articles will no longer be stored ("no matching entry in
> storage.conf").
>
> I am unsure how to best deal with that.
> If no storage class has a filtered parameter, fall back to discard that
> condition?
I've gone ahead, and implemented the following rule: if all the storage
classes have this new filtered key set to false, filtered articles are
stored in the same storage class as accepted articles. It is only when
at least one storage class has this key set to true than filtered
articles and accepted articles are no longer stored mixed together in
any storage class.
I hope this is fine for you, Christoph. At least, it preserves the
current behaviour on upgrade.
Now committed. Thanks again for your patch! (I'll look at your other
one for Path header fields soon.)
--
Julien ÉLIE
« Le cercle est le plus long chemin d'un point au même point. » (Tom
Stoppard, _Every Good Boy Deserves Favour_)
More information about the inn-workers
mailing list