The api method 'ap_escape_path_segment' does not URL-encode the '&' character.
This means that if you use it in a custom apache module, you will not be able 
to correctly encode an URL that contains parameter-value pairs separated 
with '&'. The '&' will be left unchanged, and passing this URL as a value of a 
parameter of another URL will lead to mistakingly take this unchanged '&' for a 
parameter-name separator of the new URL.

RFC 1738 says that ';', '/', '?' are reserved characters in the path and search 
components of an HTTP URL, but the BNF shows '&' as well.
It looks like the correct parameter-value separator should be ';' but we all 
know it's almost never the case (I think the CGI perl modules handles it, 
though).

The correction of this problem is rather simple:
in src/main/gen_test_char.c
replace (line 61 in 1.3.27 Solaris):
        if (!ap_isalnum(c) && !strchr("$-_.+!*'(),:@&=~", c)) {
with
        if (!ap_isalnum(c) && !strchr("$-_.+!*'(),:@=~", c)) {
and start the full compilation all over again.

The "test_char.h" generator (gen_test_char) will be modified, a new
test_char.h generated, and used in util.c with the needed values to have '&' 
url-encoded by 'ap_escape_path_segment' 

The 'ap_escape_path_segment' documentation, while short, says it is not used by 
apache. Witch is probably why this was not an issue until now...