Search squid archive

Re: Forcing Header in Reverse Proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux