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

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_at_treenet.co.nz> 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
>
Received on Mon Jan 16 2012 - 22:21:12 MST