Re: [squid-users] Forcing Header in Reverse Proxy

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
Received on Mon Jan 16 2012 - 21:55:18 MST