Hi Robert, This is a corner case, in my opinion. The wrong option is not stopping Squid3 from serving requests on another http_port, so an error printed in the log file is the best option so that an administrator can check what is working and what is not.
Printing to stderr is not a good way to notify the administrator in case of automatic and unattended start of squid3 service, which is the most common use case. If you want to check how squid3 parses the configuration file you can always use the "squid3 -k parse" command line upon changing the config file. Regards, L -- Luigi Gangitano -- <lu...@debian.org> -- <gangit...@lugroma3.org> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 GPG: 4096R/2BA97CED: 8D48 5A35 FF1E 6EB7 90E5 0F6D 0284 F20C 2BA9 7CED