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
