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.
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.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
