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]
