ReverseProxy URI stripping
9 March 2015, 19:54
I am almost positive I've asked about this before, but I rather hope the answer may have changed. =)
Say I have the following URI:
I want to use ReverseProxy in the following manner:
ReverseProxy ^/isso/.* http://127.0.0.1:1234/
:/isso/js/... is proxied as a request in the form of http:/127.0.0.1:1234/js/...
(i.e. where the /isso part of the URI is masked from the remote target)
How can that be done?
10 March 2015, 15:02
Also, if that isn't viable, is there a way to pass custom HTTP headers only when reverse proxying?
11 March 2015, 09:49
UrlToolkit rules are now processed before using a reverse proxy. So, you can use that one to rewrite /isso/ to anything else. Adding HTTP headers to requests that are reverse proxied only is not supported.
12 March 2015, 17:36
This may get a bit convoluted, I'll try to keep it simple(ish). =)
What I'm trying to achieve is this:
If the URI is /isso/.*, ReverseProxy to http://127.0.0.1:1234/ *without* /isso/. i.e.:
http://myhost/isso/js/test.js will be reverse proxied to http://127.0.0.1:1234/js/test.js
I don't think UrlToolkit will be useful here. I can Match on /isso/.* and Call isso_toolkit, then Rewrite inside the toolkit to remove /isso/, but I can't execute a ReverseProxy inside a toolkit, as far as I know (can I?).
The mystery to me remains why ReverseProxy mandates that the entire origin URI be passed without modification. Take the example straight from the man page:
Example: ReverseProxy ^/icons http://resources.lan/images
In the real world, that would mean http://myserver/icons/test.ico will be proxied to http://resources.lan/images/icons/test.ico, not http://resources.lan/images/test.ico, which was almost certainly what was intended. As implemented, ReverseProxy is really acting as more of a load-balancing function than a true reverse proxy. Why would it not be simpler, more flexible, and actually useful to apply the same rules to ReverseProxy as, say, Match/Rewrite, so you could do the following:
ReverseProxy ^/icons/(.*) http://resources.lan/images/$1 (which would produce the result I think was intended in the man page example)?
If that were the case, solving my problem elegantly via:
ReverseProxy ^/isso/(.*) http://127.0.0.1:1234/$1
would be trivial and obvious (and without actual WSGI support, increasingly difficult to handle otherwise as Python server applets continue to gain in popularity, requiring HTTP shims to work with reverse proxy solutions).
Just my soapbox thoughts...
12 March 2015, 18:57
At the moment, I'm working on the reverse proxy. In the next version, you can configure it via separate section, just like the UrlToolkit and FastCGIserver. This allows me to include more options, an UrlToolkit rule for example. If you're interested in beta-testing it, just send me an e-mail.
13 March 2015, 01:30
Mail sent to your leisink.net address.
15 March 2015, 16:11
I hope ReverseProxy under UrlToolkit section and not under new section.
15 March 2015, 18:56
I've decided not to continue with the reverse proxy section. The required code became too tricky, so I've thrown it all away. I'm now looking at making the current ReverseProxy setting more advanced.
This topic has been closed.