mod_ssl FakeBasicAuth broken for subrequests

[Sander Striker <st...@apache.org>]

Hi,

In Subversion we are seeing persistent failures with mod_ssl +
FakeBasicAuth when committing.

To give you an idea what is happening, here is the stacktrace of
where the 403 is generated:

#0  ssl_hook_UserCheck at ssl_engine_kernel.c:849
#1  0x08097ff5 in ap_run_check_user_id at request.c:112
#2  0x08098939 in ap_process_request_internal at request.c:259
#3  0x0809a541 in ap_sub_req_method_uri at request.c:1649
#4  0x4043c7ea in dav_lookup_uri at util.c:317
#5  0x40439f2a in dav_method_merge at mod_dav.c:4253
#6  0x08081185 in ap_run_handler at config.c:195
#7  0x0808179f in ap_invoke_handler at config.c:401
#8  0x0806e3f6 in ap_process_request at http_request.c:288
#9  0x080698cc in ap_process_http_connection at http_core.c:293
#10 0x0808bec5 in ap_run_process_connection at connection.c:85

Now, mod_ssl is doing FakeBasicAuth, so on the first pass at the request
it adds a new faked up Authorization header.  On the second pass, which
happens because a sub request is generated and processed, mod_ssl
sees the Authorization header and returns HTTP_FORBIDDEN:

    /*
     * Make sure the user is not able to fake the client certificate
     * based authentication by just entering an X.509 Subject DN
     * ("/XX=YYY/XX=YYY/..") as the username and "password" as the
     * password.
     */


This seems logical.  It does however mean that all subrequests
would fail with a 403 aswell, since the Auhtorization header would
already be present (since the headers were copied from the main
request).

I've committed a fix in 2.1 HEAD, but given this is mod_ssl and
an obscure feature (FakeBasicAuth), an extra pair of eyes can't hurt:

 * modules/ssl/ssl_engine_kernel.c r1.97


Sander