fair enough. How would you, then, implement the following... I would like to forward https://xyz.mydomain.com/server1 to http://server1.mydomain.com and https://xyz.mydomain.com/server2 to http://server2.mydomain.com. Please, keep in mind, the target server is apache and it has servername tag which depends on header. Thanks for your help On Mon, Jan 16, 2012 at 4:55 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > > 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 >
