Hello,
Thanks for taking a look at my modules. Indeed, I wrote them because the
current mod_unique_id and mod_substitute did not meet my needs, and both of
them was written with performance in mind.
mod_unique_id provides a unique but deterministic variable based on a
timestamp and a counter. The counter requires a lock via apr_atomic_inc32
to guarantee the correlation between requests (and could be a performance
issue). I thought this module was mainly used for correlation in a logging
system rather than for use in a security system.
mod_random was written to inject a CSP nonce into HTML files through
mod_replace. It could be possible to merge mod_random in mod_unique by
adding a flag but my personal view is I prefer a different module for each
use case.
Please find below the comparison provided by Claude between these modules.
| Feature | mod_unique_id | mod_random
|
|----------------|-------------------------------------------|----------------------------------------|
| Primary goal | Request tracking & correlation | Security
tokens & randomness |
| Uniqueness | Guaranteed globally across servers/time | Random, no
uniqueness guarantee |
| Predictability | Deterministic (contains timestamp) | Fully
unpredictable |
| Configuration | Always on |
Configurable on/off per location |
| Length | Fixed (~24 chars) |
Configurable (1-1024 bytes) |
| Use cases | Logging, request IDs, distributed tracing | CSRF
tokens, nonces, session IDs |
| Performance | Efficient (mostly increments counter) |
Re-generates random bytes each request |
mod_replace is a straightforward version of mod_substitute. In
mod_substitute, each regular expression is used to find text to replace, so
the performance of the module depends on the number of expressions used.
This is necessary because the model could be a regular expression.
I think the use case of mod_replace is simpler, as the goal of the module
is to replace fixed strings with another string (which could be a variable,
like those created by mod_random for injecting a CSP nonce into an HTML
file). The bundle of patterns is precompiled into an automaton and reused
for every request.
I asked Claude to write a benchmark based on this hypothesis (
https://github.com/PilouGit/mod_replace/blob/main/benchmark/PERFORMANCE_COMPARISON.md
Evolve mod_subtitute to use a precompile automaton could be complex and I
think useless as the use case of both module are quite different and
depends of the complexity of pattern 1. mod_substitute
-
Primary use: advanced replacements in HTTP content using regular
expressions (regex).
-
How it works: each regex is evaluated on every request to find matches.
-
Advantages: very flexible; can handle complex and dynamic replacements.
-
Disadvantages: slower if many regex patterns are used, since each
pattern is re-evaluated for every response.
-
Typical use case: dynamically modify HTML or text content based on
complex patterns, e.g., transforming URLs or specific tags in a page.
2. mod_replace
-
Primary use: simple, deterministic replacements of fixed strings.
-
How it works: patterns are precompiled into an automaton, reused for
every request without recalculating the patterns.
-
Advantages: much faster for simple replacements, especially when
injecting variable values like CSP nonces.
-
Disadvantages: less flexible; does not support complex regex.
-
Typical use case: replace fixed strings in HTTP responses, e.g.,
injecting a CSP nonce into all <script> tags in an HTML page.
Kind Regards
Le dim. 2 nov. 2025 à 03:12, Emmanuel Dreyfus <[email protected]> a écrit :
> On Sat, Nov 01, 2025 at 04:18:23PM +0100, Pierre Pilou wrote:
> > Would be interesting to merge then in the module of httpd ?
>
> Hello
>
> I had a look at your two modules, and my first impression is that
> they partially overlap existing ones. I only had a quick look, do
> not hesistate to tell me if I am wrong.
>
> mod_replace seems to do the same functionnality as mod_substiture
> with the n flag, but it adds environement variable substitution.
> Did you consider extending mod_substitute? You could add a flag
> so that the RHS is treated as an apache expression, which would
> allox environment variable substitution, and more:
> https://httpd.apache.org/docs/current/en/expr.html
>
> mod_random seems to extend mod_unique_id, by making the random
> data more random (using apr_generate_random_bytes instead of
> ap_random_insecure_bytes) and with a configurable length. Here
> again, you could extend mod_unique_id, by adding directives so
> that the administrator can set true or insecure randomness,
> chose generated data length, and environment variable name.
>
>
> --
> Emmanuel Dreyfus
> [email protected]
>
