On Thu, Feb 5, 2026 at 12:02 PM Mark Thomas <[email protected]> wrote:
> Expanding the reverse proxy testing sounds good to me. > > Just some thoughts. > > The OCSP experience of setting up a proper OCSP responder via an > external process - and particularly managing that process if the test > fails - makes me wonder if we want to continue down that road. At the > back of my mind has been writing a minimal Java version of an OCSP > responder that works with our tests to avoid that issue and remove the > use of an external native process during testing. > > There are some reverse proxy tests in WebSocket that are disabled by > default as they expect the external proxy to be up and running. > > If we want to test the reverse proxy specific features in Tomcat then an > alternative approach is to expand the existing HTTP and AJP clients so > we have precise control over what is sent to Tomcat. I'd expect that > this is the only way we'd be able to test most of the error cases as a > "proper" reverse proxy won't send the invalid data. > > If you do go the external process route, it gets "interesting" for > Windows if you want to test IIS as each Windows version has its own IIS > version. Last time I checked (a few years ago) the setup instructions > were consistent across all current versions but there have been times > when different versions have needed slightly different steps to set up. > > > On Wed, Feb 4, 2026 at 7:34 PM Christopher Schultz > > <[email protected]> wrote: > > <snip/> > > >> Remember that we are all on different > >> environments: I'm primarily on Mac, Mark straddles the fence of > >> Windows/Mac, Konstantin is primarily Windows, Rémy is Linux (and I > >> assume you as a Red Hatter are also on Linux), and Rainer has a zoo of > >> *NIX environments on which to test. > > I do most of my work on Linux these days although I do have a bunch of > Windows and Linux VMs for testing as well as $work's Mac. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > All, After realizing that creating a Java harness to provision a test environment would essentially reinvent the wheel, and that the complexity of building httpd as part of the test flow would defeat the purpose, I decided to use the external process approach and implement an integration testsuite under the regular test directory. Those tests are excluded from the default test target, i.e. "ant test". They can be ran with "ant test -Dtest.profile=integration" and they expect an httpd installation directory to exist on the PATH or to be defined by "test.httpd.path" as I've thoroughly described in the BUILDING.txt file. I’ve verified the implementation on Linux and Windows, but I don't have a macOS machine to test on. Thus, I would be grateful if somebody could give it a quick run on macOS. I will wait a couple of days for potential feedback; if no issues arise, I will backport the commits. My next steps are to utilize mod_jk, mod_cluster and relevant modules in the testsuite. Kind regards, Dimitris
