Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7D28010D9C for ; Wed, 25 Sep 2013 09:07:18 +0000 (UTC) Received: (qmail 74177 invoked by uid 500); 25 Sep 2013 09:07:04 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 74115 invoked by uid 500); 25 Sep 2013 09:07:01 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 74102 invoked by uid 99); 25 Sep 2013 09:06:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Sep 2013 09:06:59 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of thomas.r.w.eckert@gmail.com designates 209.85.217.169 as permitted sender) Received: from [209.85.217.169] (HELO mail-lb0-f169.google.com) (209.85.217.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Sep 2013 09:06:54 +0000 Received: by mail-lb0-f169.google.com with SMTP id z5so4934708lbh.0 for ; Wed, 25 Sep 2013 02:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Kc1bX7eYmltQLIhpvZjrwfdymng6/jP3zG1ThU5oWi8=; b=d+aRS7UEcED2+etmTtNRllAfKqb1OFwbMv+WAqMKFe8WFmN/ynhhDsKlJIQOzkxQsr pYh9TNbaremG/IjwD98Hy3DOXEYF7pj26n6Fsf6+2v92rERkatlMtfZhOqJ6qHFx1mib VxQvVQ6ubrWanUi9qg0F84t4sKkBr+UqvrdQZHELd788yYfM3iLCbdz1g0hCO2JU+o86 9QnE6rfqZtiwTdh1U6J7twb04tyI9bnimTECpwdwePvqmNEJvdv4LLzvZ1yzKgszYPm4 iIl/DE7vUwcBvw7lTjOt4QcgTYW3UTKN3QHLD2nmqCd11ykMF/2UbfEyy/dqMju49Sf+ V1kw== MIME-Version: 1.0 X-Received: by 10.112.52.225 with SMTP id w1mr1007082lbo.31.1380099993165; Wed, 25 Sep 2013 02:06:33 -0700 (PDT) Received: by 10.112.161.229 with HTTP; Wed, 25 Sep 2013 02:06:33 -0700 (PDT) Date: Wed, 25 Sep 2013 11:06:33 +0200 Message-ID: Subject: ProxyPassReverse and regex From: Thomas Eckert To: dev@httpd.apache.org Content-Type: multipart/alternative; boundary=001a11c3fe90d8e62804e731910a X-Virus-Checked: Checked by ClamAV on apache.org --001a11c3fe90d8e62804e731910a Content-Type: text/plain; charset=ISO-8859-1 I'm facing the problem that I have to use ProxyPassReverse inside a container, which is not really supported as documented in the last paragrpah at http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse I find the 'workaround' mentioned in the docs quite useless: "The same occurs inside a section, but will probably not work as intended, as ProxyPassReverse will interpret the regexp literally as a path; if needed in this situation, specify the ProxyPassReverse outside the section, or in a separate section." How is this supposed to help me when facing such a situation ? If I need to have ProxyPassReverse understand a regex then it will not do so just because I placed it outside of the container since it *always* understands the path argument as literal string - or did I miss anyhing when looking at the ProxyPassReverse code ? In my concrete situation I have a container with a negative lookahead which I need to have ProxyPassReverse understand somehow. I'm thinking of patching ProxyPassReverse using the ProxyPassMatch code so it understands regexps correctly. However, this has surely been considered before and I'm wondering why it was not put in - after all similar code exists for ProxyPassMatch. Are there pitfalls which I haven't seen yet ? Some time ago I dig into some issues I had with using directives inside a container instead of a container. I remember being told in IRC behaves less like a and more like a internally. Might this be connected to 'ProxyPassReverseMatch' not existing ? Cheers, Thomas --001a11c3fe90d8e62804e731910a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm facing the problem that I have= to use ProxyPassReverse inside a <LocationMatch> container, which is= not really supported as documented in the last paragrpah at http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxy= passreverse

I find the 'workaround' mentioned in the docs quite usele= ss:

"The same occurs inside a <LocationMatch> section, = but will probably not work as intended, as ProxyPassReverse will interpret the regexp literally as a path; if needed in this situation, specify the ProxyPassReverse outside the section, or in a separate <Location> section."

How is this supposed to help me when facing such a situation ? If I nee= d to have ProxyPassReverse understand a regex then it will not do so just b= ecause I placed it outside of the <LocationMatch> container since it = *always* understands the path argument as literal string - or did I miss an= yhing when looking at the ProxyPassReverse code ?

In my concrete situation I have a <LocationMat= ch> container with a negative lookahead which I need to have ProxyPassRe= verse understand somehow. I'm thinking of patching ProxyPassReverse usi= ng the ProxyPassMatch code so it understands regexps correctly. However, th= is has surely been considered before and I'm wondering why it was not p= ut in - after all similar code exists for ProxyPassMatch. Are there pitfall= s which I haven't seen yet ?

Some time ago I dig into some issues I had with using directives inside= a <LocationMatch> container instead of a <Location>=20 container. I remember being told in IRC <LocationMatch> behaves less= =20 like a <Location> and more like a <Directory> internally. Might= this be connected to 'ProxyPassReverseMatch' not existing ?

Cheers,

=A0 Thomas

--001a11c3fe90d8e62804e731910a--