On 17.01.2012 04:15, Roman Gelfand wrote:
I made several mistakes in my original post. So, I am rewriting it
here...
I have setup configuration to forward requests to a backend
server...
acl mail urlpath_regex ^/mesg
https_port 443 cert=/etc/certs/mail.pem key=/etc/certs/mail.key vhost
vport
cache_peer mail.mydomain.com parent 80 0 no-query originserver
name=mail login=PASS
cache_peer_access mail allow mail
cache_peer_access mail deny all
http_access allow mail
The problem is host mail resolves to mesg.mydomain.com instead of
mail.mydomain.com. How can I force the header to be
mesg.mydomain.com?
My original questions about *why* you need to do this rather nasty and
problematic change on production traffic are still not answered...
On Mon, Jan 16, 2012 at 12:25 AM, Amos Jeffries wrote:
Its not clear why you need to force anything. Surely the server at
"host.mydomain.com" has been correctly setup to host all of the FQDN
which
are passed to it?
Note that what the FQDN resolves to should be the Squid IP address.
This
resolution is done only by the client and is completely separate to
the
*textual* FQDN label which remains unchanged when passing through
Squid to
the server. The config demos show it using dstdomain to test the
*textual*
FQDN label for acceptible values instead of resolving the IP or
other
complex things by reason of domain FQDN being the most stable and
dependable
property of the traffic.
To explain why I'm making a point about considering the "why":
Re-writing these things to specific values hits a lot of problems
directly attributable to the server outgoing traffic all being about the
forced domain rather than the domain the client is aware of. Followup
responses from the client disappearing, links being "broken", internal
structure being revealed, validation miss-match errors, XSS leaks etc.
are all common and well known side effects of re-writing details in the
middle of a client-server transaction. There are whole RFCs related to
the same problems when they occur in NAT systems, which are just the IP
address version of this.
Identifying and avoiding all the effects is often more difficult than
fixing the server and making the middle a simple relay. A little extra
trouble at the start avoiding it will save a lot of headaches for both
yourself and every other network involved in the traffic.
If you are happy to face down all those problems and your Squid is
recent enough (2.7 or 3.1 series, some late 2.6 series) it will support
the forcedomain= option on the cache_peer line.
Amos
