On Tue, Feb 24, 2026 at 6:36 PM Christopher Schultz <
[email protected]> wrote:

> Dimitris,
>
> On 2/24/26 9:40 AM, Dimitris Soumis wrote:
> > 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'll see what I can do. Do I need anything besides a binary httpd
> available? I don't have a source installation, for example, at the moment.
>

A binary httpd with the following modules available should be enough:

        - mod_proxy
        - mod_proxy_http
        - mod_headers
        - mod_ssl
        - mod_authz_core
        - mod_unixd
        - mod_mpm_event

If a test requires a module that is not available, then the test is
skipped. Thus, no failures should occur.

 Thanks!


> > 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.
>
> I'd recommend focusing on mod_proxy_* instead of mod_jk unless you have
> a personal or professional interest in mod_jk. I have a long-term goal
> of pushing everyone from mod_jk -> mod_proxy_http.
>

Ack.


>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to