https://bz.apache.org/bugzilla/show_bug.cgi?id=59319
--- Comment #1 from Rainer Jung <[email protected]> --- You scheme/host/port part of the target URI is "http://${proxytouse}";. Any setting added to this ProxyPass via key=value will be saved under this worker name. Later during request runtime, the "${proxytouse}" will first be resolved to a real hostname plus port, say host1 and port1. Then a worker is being looked up under this hostname and port, ie. "https://host1:port1";. Since no worker like that was defined in the config, the default reverse proxy worker will be used, which doesn't have these key=value settings applied (and you'll also probably not get connection pooling). If you need to work with host and port provided by a script, and the list of possible hosts plus port pairs is not too long to maintain, you should configure the workers for those backends, so you get connection pooling an the actual key=value settings you like. Example: Suppose myhost:myport is one of the values returned by you script, then add <Proxy "https://myhost:myport";> ProxySet connectiontimeout=5 timeout=30 </Proxy> to your config (and you can remove those key=value parts from you interpolated ProxyPass. I think it's useless there. You can get a bit more insight about which workers are used etc. by setting LogLevel to trace8 or at least the LogLevel of mod_proxy to trace8 ("LogLevel info proxy:trace8"). If you don't like repeating those <Proxy> blocks for all you backends, you can define a macro using mod_macro: <Macro MyWorker $hostAndPort> <Proxy "https://${hostAndPort}";> ProxySet connectiontimeout=5 timeout=30 </Proxy> </Macro> and then use the macro: Use MyWorker host1:port1 Use MyWorker host2:port2 ... That reduces the redundancy in repeating the communication settings for each Worker. The macro name "MyWorker" can be replaced by something more meaningful for you. If the number of host/port pairs is really huge, then it is possible that you really don't want pooling, because reusing existing connections before they time out might be rare. In that case using the default reverse proxy worker for all those backend connections should be OK and you wouldn't explicitly define workers. Unfortunately IMHO we currently lack a way of defining worker params (key=value) as default for all workers and/or for the default (reverse) proxy worker. So in that case there's be no way of defining e.g. the connectiontimeout etc. Whether the fact, that using key=value does not work, if the worker has scheme, host name or port interpolated is a bug or not can be discussed. I'd say from teh current implementation it is not expected to work, but we could maybe log a warning if you try to use that pattern. Let's see what others comment. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
