Re: [squid-users] How to change redirection path to forward to www.earth.com/moon insted of moon.earth.com ?

On 11/04/2014 3:56 a.m., Strafe wrote:
> Can someone please advise me about a problem that I have.
>
> I'v deployed Squid3 Reverse Proxy Server. I have one server in the internal
> network that is forwarded through Squid.
>
> My external network is called earth.com and the internal server is called
> moon.
> I'v managed to set Squid to forward packets that come for moon.earth.com to
> internal server moon which is on IP 192.168.1.10
>
> My question is: How can I setup Squid to forward packets when it receives
> http://www.earth.com/moon instead of the current setup -
> http://moon.earth.com

Firstly, Squid does not forward packets. Squid forwards HTTP messages.

What you ask can be done in several ways ...

1) Stick with the current setup mapping only the domain names.
It is both the Right Way to map HTTP requests between domains and avoids
many complications and problems.

For your existing config:
 * drop the cache_peer_domain directive
 * Make the internal server aware that it is servicing the public domain
www.earth.com and the entire HTTP ecosystem will operate as designed by
RFC 2616 specifications.
 ** Virtual hosting is your friend **

2) If you can, setup a URL redirection which forwards clients to the new
URL. This is the Right Way to make a URL point at a different URL in HTTP.

 a) Squid-3.2 and newer can setup a redirection like so:
   acl foo dstdomain moon.earth.com
   deny_info 302:http://moon.earth.com/moon%R foo
   http_access deny foo

 b) Squid-3.1 and older you need to setup a URL redirector to emit 30x
status code and the new URL:

   acl foo dstdomain moon.earth.com
   url_rewrite_program /somescript
   url_rewrite_access allow foo

Doing (2) in either form requires that both www.earth.com and
moon.earth.com are visible and available to the public clients.

3) if you really have no choice at all you. And I mean that very
seriously - this is an absolute last resort.
 You can setup a URL-rewriter program like (2a) above, but omitting the
30x status code. This changes the URL delivered to the peer server but
leaves the client thinking its accessing moon.earth.com URLs.

When undertaking (3) you had best audit your site code, contents, and
user abilities to ensure that:
 * server MUST NOT generate any absolute-URLs using the domain which the
webserver is asked for.
 * page content MUST NOT use any relative-URL beginning with '/'
characters. Unless they are prefixed /moon by the origin server.
 * Content-Disposition headers meet the criteria above
 * Content-Location headers meet the criteria above
 * Location headers meet the criteria above

... anything containing URLs must meet the absolute-URL and relative-URL
criteria.

These conditions apply to URLs *anywhere* in the HTTP protocol and
content objects emitted by the web server application. Generated and
static content alike is affected, as are compressed archives with URL
"file" meta tags and DB entries of user input URLs. *anything* with URLs.
 If any one of these conditions on URL-rewriting are missed during your
audit, or future site changes cause one to be untrue. Then the clients
receiving traffic with those broken URL details will encounter issues of
various types trying to access or use them.

HTH
Amos
Received on Fri Apr 11 2014 - 04:58:14 MDT