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