Forum

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:

/isso/js/...

I want to use ReverseProxy in the following manner:

ReverseProxy ^/isso/.* http://127.0.0.1:1234/

such that

:/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?

Rodney

Also, if that isn't viable, is there a way to pass custom HTTP headers only when reverse proxying?

Rodney

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.

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...

Rodney

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.

Mail sent to your leisink.net address.

Rodney

I hope ReverseProxy under UrlToolkit section and not under new section.

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.