1 |
On Tue, 05 May 2009 22:28:22 +0100 |
2 |
Steve <gentoo_sjh@×××××××.uk> wrote: |
3 |
|
4 |
> Sascha Hlusiak wrote: |
5 |
> > The easiest thing would probably be to just use ssh port forwarding because |
6 |
> > you already have all the pieces running anyway. Wouldn't a simple |
7 |
> > |
8 |
> > ssh -L 12345:secondapache:https user@remotessh |
9 |
... |
10 |
> I really want to avoid having to access a non-standard port from the |
11 |
> URLs - I want to use the final URLs exactly as they will be once the |
12 |
> in-development website is eventually deployed. |
13 |
|
14 |
But you don't have to! |
15 |
Just setup first apache to forward requests to the second one in any |
16 |
way you like using mod_rewrite: |
17 |
|
18 |
RewriteRule /remote/(.*) http://localhost:1235/$1 [P] |
19 |
|
20 |
The rule might need some correction, but it's here just to illustrate |
21 |
the point. That way you can bind any number of "remote" servers to |
22 |
local urls, served (in the end) by the same apache. |
23 |
|
24 |
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html |
25 |
|
26 |
Also I think it's worth mentioning that apache isn't well suited for |
27 |
such a tasks if both local and remote targets get similar load - lite |
28 |
frontend server or reverse proxy (like nginx, lighttpd, squid, haproxy |
29 |
etc) should save a lot of workload. |
30 |
Even more, if you'll make it serve static content as well, and |
31 |
optimally get apache out of the equation at all ;) |
32 |
|
33 |
Another point is that apache isn't any good at mangling http headers as |
34 |
well, so you should make sure that remote scripts won't redirect user |
35 |
to 'localhost:12345' or use HTTP_HOST var from CGI interface (since |
36 |
it'd be set to the same localhost), using *_X_* vars instead. |
37 |
Alternative is, again, to install something that can mangle headers |
38 |
and that's any of the daemons mentioned above. |
39 |
|
40 |
-- |
41 |
Mike Kazantsev // fraggod.net |