[squid-dev] [PATCH] Make Squid death due to overloaded helpers optional

[Alex Rousskov]

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.