On 08/09/2016 06:19 PM, Henrik Nordström wrote: > tis 2016-08-09 klockan 11:47 -0600 skrev Alex Rousskov: >> >> Yep, that matches both my understanding and motivation to return ERR >> in the explicitly configured on-persistent-overload=err case.
> I'd say make it configurable. > > on-persistent-overload=abort/err/ok/unknown > > to represent all three possible states. Agreed (as a TODO for somebody who has a corresponding use case). We are laying the framework for that future enhancement, but should not be forced to implement it, especially because returning OK responses will probably require more configuration and perhaps even helper-specific code. > But that is based on the assumption that unknown is "outcome is not > known" and that Squid then skips the access rule and looks at next > rule. Have not looked in detail in how current Squid operated with > these conditions. The uncertainty about "unknown" is one more reason to leave enabling that as a TODO for those with a use case. > Starting with only abort/err is good. err should then map to the same > as a negative helper response which is the most clear buldingblock to > work with then bulding access lists. > > It does not make sense that err in this context should map to different > logics depending on the directive. Agreed, and the take #10 implementation posted earlier appears to implement the "err" case correctly AFAICT. As Amos has noted, we do need to restore the old "unknown" behavior when the helper is _missing_ (and not overloaded), but that is a completely different problem with a simple solution: SubmissionFailure() should use Helper::Unknown when its hlp parameter is nil and Helper::Error. Cheers, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
