>>so, if I understand the debate, it's whether this ability should remain >>solely with mod_proxy, or whether other modules should be allowed to decide >>whether they should set 'ProxyRequest On' at runtime. >> >>is that right? > > > Yup.
I guess I could go either way. part of me thinks that this entire thing should be pluggable, that modules other than mod_proxy should be able to tell mod_proxy (or a different proxy module) to wake up and step in using a common interface. that's a pretty strong feeling, since it seems like a nice architecture. but a cursory look at the proxy code seems to indicate that it's not quite as simple as setting r->proxyreq any more, so things start to fall apart. on the other side, I'm not sure how many people are taking advantage of the 1.3 behavior - both the eagle book (IIRC) and cookbook say you need to explicitly configure httpd.conf. the only thing I would want to make sure of is that we can turn forward proxying _off_. that is, there are lots of examples out there on how to intercept a proxy request and serve it up from disk instead of letting mod_proxy farm it out. _that_ is extremely valuable from a perl perspective. > And to be clear: t/modules/proxy.t does not test the operation of > a forward proxy - it tests the operation of a reverse proxy but sets > r->proxyreq to the wrong value, which happened to work before. > > If it used r->proxyreq = PROXYREQ_REVERSE it should work again with the > httpd trunk. yes, I was waiting to change that until we sorted this all out. thanks for the reminder. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
