Return-Path: Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: (qmail 76870 invoked from network); 15 Jun 2010 12:37:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Jun 2010 12:37:10 -0000 Received: (qmail 85450 invoked by uid 500); 15 Jun 2010 12:37:10 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 85085 invoked by uid 500); 15 Jun 2010 12:37:07 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 85072 invoked by uid 99); 15 Jun 2010 12:37:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 12:37:05 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.216.173] (HELO mail-qy0-f173.google.com) (209.85.216.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 12:36:58 +0000 Received: by qyk32 with SMTP id 32so174430qyk.18 for ; Tue, 15 Jun 2010 05:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.65.221 with SMTP id k29mr3120609qai.130.1276605396648; Tue, 15 Jun 2010 05:36:36 -0700 (PDT) Received: by 10.220.124.233 with HTTP; Tue, 15 Jun 2010 05:36:36 -0700 (PDT) Date: Tue, 15 Jun 2010 20:36:36 +0800 Message-ID: Subject: mod_proxy per-directory settings handling From: mike venzke To: modules-dev@httpd.apache.org Content-Type: multipart/alternative; boundary=000feaf371482f85b3048910dbcf X-Virus-Checked: Checked by ClamAV on apache.org --000feaf371482f85b3048910dbcf Content-Type: text/plain; charset=ISO-8859-1 We've been trying to reconcile various issues in config file Location inheritance in httpd 2.2. In reading the core code, we've determined that Locations truly are read and merged in order, and the most-specific (longest Location strings) should go last. Therefore, we order our Locations in increasing length order. However, this caused some value inheritance problems in some modules. In some, there were issues with "*_set" variables not being properly merged, so some boolean values wouldn't merge right. We've resolved those, but there continue to be problems in some configuration settings in mod_proxy that we've added, even though the per-dir merging appears to be valid. We believe we've tracked this down to how mod_proxy translates urls, in "proxy_trans()". It iterates conf->aliases->nelts in forward order, and stops once it finds a match. Assuming standard apache config ordering of least-specific to most-specific, this will stop at the first matching path, likely "/". If they later have underlying Locations, like "/images/", it won't be matched here, even if the url is within "/images/". I'm not exactly clear on what part of this hook is then setting some variable that determines which per-dir config to use in the proxy handler, maybe it's just because filename is set here. Either way, reversing the order of the iteration through the conf->aliases in "proxy_trans()" seems to achieve what we want. Now, the variables are using their most-specific setting. As far as I can understand, starting at the most-specific and stopping at the first match won't affect variable inheritance from some less-specific Location, because that's all handled elsewhere when the configs are merged. This hook is only about translating the proxied url, so there's no need to go through all the Locations, but it is important to pick only the most-specific Location. I can't find a bug report about this or talk on this list, but it seems like something that other people would have complained about if it's true, but to us it sure seems like it is. Am I wrong? Is there some other reason why mod_proxy needs to go through the aliases in forward order, maybe related to regex matching? Thanks, - Mike --000feaf371482f85b3048910dbcf--