On 26.11.2013 06:31, Kaspar Brand wrote:
> As far as PR 55782 is concerned, the problem might be that
> proxy_util.c:ap_proxy_determine_connection() does not take Host: header
> differences into account when checking if an existing connection can be
> reused (not sure). With SNI this would have the effect that the hostname
> from the TLS handshake is causing the mismatch with the Host: header.
To clear this up: the above guess was a red herring. mod_proxy's current
behavior is fine in this aspect and does not conflict with any IP resolution
"coincidence" when reverse proxying SNI-based URLs (I'm aware that this
thread is supposed to deal with forward proxying only, but am adding this
for posterity, in case someone is sifting through archives).
It's not ap_proxy_determine_connection() which is really relevant, but
proxy_util.c:ap_proxy_get_worker() instead. mod_proxy (only) reuses workers
for reverse proxying based on the target URL; looking at
proxy_util.c:ap_proxy_get_worker() in 2.4 e.g we see:
/*
* Do a "longest match" on the worker name to find the worker that
* fits best to the URL, but keep in mind that we must have at least
* a minimum matching of length min_match such that
* scheme://hostname[:port] matches between worker and url.
*/
if (balancer) {
proxy_worker **workers = (proxy_worker **)balancer->workers->elts;
for (i = 0; i < balancer->workers->nelts; i++, workers++) {
worker = *workers;
if ( ((worker_name_length = strlen(worker->s->name)) <= url_length)
&& (worker_name_length >= min_match)
&& (worker_name_length > max_match)
&& (strncmp(url_copy, worker->s->name, worker_name_length) ==
0) ) {
max_worker = worker;
max_match = worker_name_length;
}
}
} else {
worker = (proxy_worker *)conf->workers->elts;
for (i = 0; i < conf->workers->nelts; i++, worker++) {
if ( ((worker_name_length = strlen(worker->s->name)) <= url_length)
&& (worker_name_length >= min_match)
&& (worker_name_length > max_match)
&& (strncmp(url_copy, worker->s->name, worker_name_length) ==
0) ) {
max_worker = worker;
max_match = worker_name_length;
}
}
}
I.e., there's no risk of two workers for reverse proxying, say,
https://foo.example.net and https://bar.example.net, ever being reused for
each other, irrespective of whether foo.example.net and bar.example.net
resolve to the same IP address.
Kaspar
