Re: [RFC] unified port directive

On 12/06/2014 8:09 a.m., Alex Rousskov wrote:
> On 06/11/2014 05:15 AM, Amos Jeffries wrote:
>>>> On 06/10/2014 12:09 AM, Kinkie wrote:
>>> I had understood that it would eventually be a catch-all directive
>>> for all squid service ports (possibly including FTP etc).
>
>> That was indeed the long term intention.
>
> If the long-term plan is to replace all *_port option with a single
> "port" or "listen" option, then I would like to hear why we should do
> that. The analysis presented so far was specific to HTTP (including
> HTTPS) so it does not really apply any more. Needless to say, the end
> goal has significant influence on the new directive name and internal
> code design.

Yes the only ports we have to backward-compat with this are the
http_port and https_port. No other port has separate TCP and TLS variants.

>
> For example, why replacing http_port and snmp_port with "port http" and
> "port snmp" is better than having distinct protocol-specific directives
> for those two protocols?

Today we have to configure (and explain to people):

 XY_port ... Y protocol=X
or
 XY_port ... Y
or
 X_port ... protocol=X
or
 X_port ... Y

NP: the *long-term* goals working towards is:

  port ... protocol=X
or
  port ... Y protocol=X

Today I am tryingto get rid of the XY_port variants as unnecessary
duplication with "X_port ... Y" variants.

Removing the need for 's' in http(s)_port with existing "ssl" parameter.

When FTP transfer protocol is added is the time to determine if the fpt_
prefix is actually necesary or the *existing* protocol= parameter can be
used alone. FWIW the only strong reason http_ and https_ are currently
used is to determine which of the split config option lists to add the
PortCfg to. And this proposed step removes that need.

>
> Replacing all current Squid directives with
>
> squid old_directive_name_here old_options_here ...
>
> is obviously a bad idea. Thus, at some unknown point(s), merged
> directives become worse than dedicated ones. I suspect the key here is
> the amount of overlapping port options and typical configuration
> combinations. Is there enough common things about all Squid listening
> ports to warrant their merger?

shared needs by all ports, both existing and needed functionality:
 - host/ip:port resolution
 - select loops prioritization over other ports
 - SSL/TLS/DSTS options
 - startup/shutdown operation and timings

shared by TCP ports:
 - TcpAcceptor class

shared by UDP ports:
 - recv
 - separate outgoing IP:port selection

Note that the difference between TCP and UDP classes is the listen
logic, which is initiated after the config lines is fully received.

Amos
Received on Thu Jun 12 2014 - 09:02:07 MDT