dual-use http_port

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 24 Oct 2012 18:00:31 -0600

Hello,

    I am facing a deployment case where a single http_port address is
used for both direct and intercepted traffic. It appears to work in
Squid v3.0, possibly using some small custom hacks (I do not know the
details). The deployment scenario requires such dual use to continue,
unfortunately.

I believe I have heard that such "dual use" ports are a bad idea and
will not be officially supported. I cannot find specific references to
that though, so perhaps I misunderstood. Can somebody confirm?

While I personally very much prefer clean setups where each port is
doing its own thing, is dual use really such a terrible thing that it
must be banned even in environments where it can be made to work and is
required by forces outside our control?

I am speculating that we could officially support it (where possible) in
a reasonably clean way using the following configuration sketch:

    http_port ip:port direct ... options for direct port ...
    http_port ip:port intercept ... options for intercept port ...

plus some piece of smart code that determines whether it is dealing with
direct or intercepted connection and switches to the right http_port
option ASAP. Note that the "ip:port" parameters are the same for both
http_port lines, indicating admin intent to enable dual use.

This way, there is a clear separation of options and internal state
except for the "short moment" when some "smart code" determines which
port it must use. That code might assume/use direct port by default (or
even have a dedicated "http_port ip:port dual" line with the same
ip:port address, if really needed!).

If we are worried about folks accidentally configuring dual ports where
none are really required, then the support for this messy setup can
require a special "shared" http_port option or even a ./configure parameter.

What do you think?

Thank you,

Alex.
Received on Thu Oct 25 2012 - 00:00:39 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 25 2012 - 12:00:08 MDT