httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 51707] New: ProxyPassReverse issues within <Location> (different to 38864)
Date Mon, 22 Aug 2011 17:40:34 GMT

             Bug #: 51707
           Summary: ProxyPassReverse issues within <Location> (different
                    to 38864)
           Product: Apache httpd-2
           Version: 2.2.19
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_proxy
    Classification: Unclassified

mod_proxy uses a per-dir config to store everything, including
ProxyPassReverse. ProxyPassReverse, by necessity actually operates on the real
domain (the right-hand side) rather than the fake (the left-hand side or
<Location> path).

This means that for the use of ProxyPassReverse inside <Location> unless the
request that caused the 301 or 302 comes from inside the Location, the
ProxyPassReverse can never trigger.

As well as this, the ProxyPassReverse walk is first-match (proxy_util.c:
    for (i = 0; i < conf->raliases->nelts; i++) {
            if (l1 >= l2 && strncasecmp(real, url, l2) == 0) {
                u = apr_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
                return ap_construct_url(r->pool, u, r);
), and when we merge the per-dir config (mod_proxy.c:
static void *merge_proxy_dir_config(apr_pool_t *p, void *basev, void *addv)
    proxy_dir_conf *new = (proxy_dir_conf *) apr_pcalloc(p,
    proxy_dir_conf *add = (proxy_dir_conf *) addv;
    proxy_dir_conf *base = (proxy_dir_conf *) basev;
    new->raliases = apr_array_append(p, base->raliases, add->raliases);
), we helpfully append the more specific ProxyPassReverses after the less
specific ones, meaning that they'll never override properly.

Unfortunately I can see both sides of the argument for ProxyPassReverse to be
Location-specific. (the same proxy may be used by two different things), but
either way, the ordering of the append above must be wrong.

I've been wondering instead about having a single insertion-sorted list so that
most-specific always comes first, but then there is the difficulty above.
Perhaps you insert into both, and then if you have a per-dir thing you use
that, but if you don't you fall back to the global list, which then takes both
sides and has the most expected behaviour.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message