On 31/01/2014 12:17 p.m., Alex Rousskov wrote:
> On 01/30/2014 03:35 PM, Amos Jeffries wrote:
>
>> P4-b: Shall we skip the arguing and go straight to ACL driven in that
>> format? I think it may be faster to simply write up a patch for ACLs
>> with a default "allow all" and simply allow/deny action choice than to
>> continue discussions around the on/off scoping. We are clearly focusing
>> on different use-cases and error conditions being more or less
>> subjectively important. The admin on the ground can probably get that
>> right far better than we can anyway.
>
> Do you want me to add an ipv4_server and ipv6_server hard-coded ACLs?
> They would work in contexts where the server address is known (any
> origin server: HTTP, FTP, Gopher, etc.). I fear opening another big can
> of worms with this! If we do not add those ACLs, how will an admin know
> that Squid is going to talk to an IPv6 server (my definition)?
Hmm. Up to you, but I think admin are at least smart enough to figure
out the necessary ACL definition if we leave it to them.
I would put an example in the squid.conf documentation though, just like
the tcp_outgoing_address etc have.
>
> We should still keep "on" and "off" keywords for backward compatibility,
> right?
Yes.
>
> So, we will have:
>
> ftp_epsv on
> ftp_epsv off
> ftp_epsv deny ipv4_server
> ftp_epsv deny ipv6_server
>
> but folks can use other, customer ACLs instead of ipv4_server and
> ipv6_server. The action on the first matching ftp_epsv line is applied.
> Anything else for ftp_epsv?
Not that I can think of.
Amos
Received on Fri Jan 31 2014 - 04:35:50 MST
This archive was generated by hypermail 2.2.0 : Fri Jan 31 2014 - 12:00:17 MST