Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 30555200C46 for ; Wed, 29 Mar 2017 19:55:51 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2EA02160B8A; Wed, 29 Mar 2017 17:55:51 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2670A160B5D for ; Wed, 29 Mar 2017 19:55:49 +0200 (CEST) Received: (qmail 9993 invoked by uid 500); 29 Mar 2017 17:55:46 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 9979 invoked by uid 99); 29 Mar 2017 17:55:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Mar 2017 17:55:46 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 4715CC0D5B for ; Wed, 29 Mar 2017 17:55:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_NUMSUBJECT=0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id wWtQGd8l8OxU for ; Wed, 29 Mar 2017 17:55:44 +0000 (UTC) Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id BDF605F20C for ; Wed, 29 Mar 2017 17:55:43 +0000 (UTC) Received: by mail-wr0-f181.google.com with SMTP id k6so19907793wre.2 for ; Wed, 29 Mar 2017 10:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zAk3rF+cX0fmkYwDg4unhbues9MUapsOFamETbdpGsk=; b=QAxVz0ViCN7fLvxGt8s2Q6fDYwdeL8u70hmSNom+ZQ1rn6I6bpeLuUub2Mfrh01mIY J8lePrwoMRQaoHIx8DHcBn4K+sh0DpiGtDWhPrCGo5XNrhTCDGaia1zQDv1R6KEHVE9T V9XNYG7xnsSAi6OX3OMqSLePnHQStL5JqnF25xVaYMcJ7Hr7ydX7UvE3Mz/TIhpyrCyY PyyhCjH/NAA2XYsBSuqK0w3x3tpsYNqZEoTwxksraqzLH2IfXi/5PmJkrES3pehA5Cie FB/j3JxMUbiFUVJ3Hwdm4AbuAIeWPM8KACEInTq0K94TgdQ2DdLDr1a27B+U8A/vXE0l gsQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zAk3rF+cX0fmkYwDg4unhbues9MUapsOFamETbdpGsk=; b=YyGixJgj0NYjVLIz0T3gcbCoJWnvPC5HkfZ/elKgVfz2w93iX88WYzdvIo9kSXZJqO mRGp003J6JtN8+HRb/p8DS/9rbA8P9e8lF0W4RCDVyoYtZEliWJUkX0h3fsHaXFXFqIT gWy3yvFxYRTiBxsqGLHnr5TgFegtvWc6mLWQeEppI8flYhAZ2QE9I4jZQeW9NbbgK2/O plnWGrC3HvGmyYyvb99Z21zCVVMoIHT0y/UyMt2LasWSvykfs8l6Pj8bWrkxrmj0eJC8 fyjVMpXxCzwRZ6hj810noY3e0EnvYsNP6wFUG8XZql/e75MFoZgH6DgPs6uh4ZFphbzr uJUw== X-Gm-Message-State: AFeK/H09RD6PMJ1rztXCYZnVitOwpOEvVDTXwabHp/nFqyGHf0SR+k/+rT+gGR8cqd8odWq/UpUemOCv7jcLqA== X-Received: by 10.28.175.11 with SMTP id y11mr1973599wme.2.1490810142607; Wed, 29 Mar 2017 10:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.149.1 with HTTP; Wed, 29 Mar 2017 10:55:41 -0700 (PDT) In-Reply-To: References: From: Luca Toscano Date: Wed, 29 Mar 2017 19:55:41 +0200 Message-ID: To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=001a11443d18fa5072054be248a0 Subject: Re: [users@httpd] Problem when using nested if statements in apache 2.4 archived-at: Wed, 29 Mar 2017 17:55:51 -0000 --001a11443d18fa5072054be248a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2017-03-28 17:28 GMT+02:00 Luca Toscano : > > > 2017-02-21 18:45 GMT+01:00 Luca Toscano : > >> Hi Mike, >> >> 2017-02-20 18:17 GMT+01:00 Mike Schlottman : >> >>> I=E2=80=99m trying to configure apache 2.4 to show nice error pages to = external >>> users of our web site, while allowing staff to see the real error. Th= e >>> idea is to prevent exposing privileged information to the general publi= c >>> while allowing our staff to more easily debug issues on our production = web >>> site. To accomplish this I am using a combination of ErrorDocument wi= thin >>> an If statement that evaluates the header X-Real-IP which is the IP add= ress >>> of the client on my server. >>> >>> >>> >>> This seems to work, until I nest the If statements to catch all the IP >>> ranges that I am interested in. >>> >>> >>> >>> For example=E2=80=A6 >>> >>> >>> >>> ErrorDocument 404 /errors/404 >>> >>> >>> >>> will correctly show the nice 404 page for a user coming from 172.28.1.8= 4. >>> >>> >>> >>> Using this, the same user coming from 172.28.1.84 sees the nice error >>> page. >>> >>> >>> >>> ErrorDocument 404 /errors/404 >>> >>> >>> >>> >>> >>> Simmilarly the same user gets the nice error page when this code is use= d. >>> >>> >>> >>> ErrorDocument 404 /errors/404 >>> >>> >>> >>> >>> >>> The problem comes when I combine these 2 so that all users except those >>> coming from 127.*.*.* or 192.168.*.* see the nice error page. >>> >>> >>> >>> >>> >>> ErrorDocument 404 /errors/404 >>> >>> >>> >>> >>> >>> The user from 172.28.1.84 does not get the nice 404 page, but the >>> default 404 page. The IP does not match either of the ranges as obser= ved >>> when using the ranges individually, but when combined in this way it do= es >>> not work as expected. >>> >>> >>> >>> Any ideas why this is? >>> >>> >>> >> >> I reproduced your use case and from the error_log (trace8) I can see tha= t >> with nested s the second one seems not evaluated (or more precisely, >> its expression is not). In the beginning I thought it was a peculiarity = of >> how the ErrorDocument core directive settings are merged between section= s, >> but it seems not the case. >> >> From my point of view, a container like should be used like other >> similar directives like and , where this use case >> would look a bit weird. The naming brings up conventions that we us= e >> in traditional programming languages, so this might be the source of the >> confusion. >> >> For your specific use case, I'd have done something like the following: >> >> > %{HTTP:X-Real-IP} -ipmatch '192.168.0.0/16' "> >> ErrorDocument 404 "My awesome error" >> >> >> or maybe using /. >> >> http://httpd.apache.org/docs/current/sections.html shows a little >> paragraph about "Nesting of sections", but I don't see any reference of >> your use case. I'll dig a bit more during the next days to find a better >> explanation if nobody will come up with a better solution :) >> >> > > It took me a while (and I forgot to update the list) but I double checked > and currently httpd does not allow nested sections. I updated the > following doc pages to warn users: > > http://httpd.apache.org/docs/current/sections.html > https://httpd.apache.org/docs/2.4/mod/core.html#if ("Not a scripting > language") > > I am currently investigating if http://home.apache.org/~ > elukey/httpd-trunk-core-nested_if_blocks.patch solves the problem; if > anybody wants to help testing please let me know :) (you can apply the > patch to the latest 2.4.x branch cleanly and recompile). > Too soon, I found some corner cases that require more work to get fixed. Will update the list once done for anybody interested :) Luca --001a11443d18fa5072054be248a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2017-03-28 17:28 GMT+02:00 Luca Toscano <toscano.luca@gmail.com= >:


2017-02-21 18:45 GMT+01:00 Luca Toscano <toscano.luca@gmail.com>:
Hi Mike,

2017-02-20 18:17 GMT+01:00 = Mike Schlottman <mschlott@spe.org>:

I=E2=80=99m trying to configure apache 2.4 to show n= ice error pages to external users of our web site, while allowing staff to = see the real error.=C2=A0=C2=A0 The idea is to prevent exposing privileged = information to the general public while allowing our staff to more easily debug issues on our production web site.=C2=A0=C2=A0 = To accomplish this I am using a combination of ErrorDocument within an If s= tatement that evaluates the header X-Real-IP which is the IP address of the= client on my server.

=C2=A0

This seems to work, until I nest the If statements t= o catch all the IP ranges that I am interested in.

=C2=A0

For example=E2=80=A6

<If=C2=A0 "! %{HTTP:X-Real-IP}=C2=A0 -ipmatc= h '172.28.1.84/32' ">

=C2=A0 ErrorDocument 404 /errors/404

</If>

will correctly show the nice 404 page for a user com= ing from 172.28.1.84.

=C2=A0

Using this, the same user coming from 172.28.1.84 se= es the nice error page.

<If=C2=A0 "! %{HTTP:X-Real-IP}=C2=A0 -ipmatc= h '127.0.0.0/8'= ; ">

=C2=A0 ErrorDocument 404 /errors/404

</If>

=C2=A0

Simmilarly the same user gets the nice error page wh= en this code is used.

<If=C2=A0 "! %{HTTP:X-Real-IP}=C2=A0 -ipmatc= h '192.168.0.0/16' ">

=C2=A0 ErrorDocument 404 /errors/404

</If>

=C2=A0

The problem comes when I combine these 2 so that all= users except those coming from 127.*.*.* or 192.168.*.* see the nice error= page.

<If=C2=A0 "! %{HTTP:X-Real-IP}=C2=A0 -ipmatc= h '127.0.0.0/8'= ; ">

=C2=A0 <If=C2=A0 "! %{HTTP:X-Real-IP}=C2=A0 = -ipmatch '192.168.0= .0/16' ">

=C2=A0=C2=A0=C2=A0 ErrorDocument 404 /errors/404<= /u>

=C2=A0 </If>

</If>

The user from 172.28.1.84 does not get the nice 404 = page, but the default 404 page.=C2=A0=C2=A0 The IP does not match either of= the ranges as observed when using the ranges individually, but when combin= ed in this way it does not work as expected.

=C2=A0

Any ideas why this is?

=C2=A0


<= /div>
I reproduced your use case and from the error_log (trace8)= I can see that with nested <If>s the second one seems not evaluated = (or more precisely, its expression is not). In the beginning I thought it w= as a peculiarity of how the ErrorDocument core directive settings are merge= d between sections, but it seems not the case.

Fro= m my point of view, a container like <If> should be used like other s= imilar directives like <Directory> and <Location>, where this u= se case would look a bit weird. The <If> naming brings up conventions= that we use in traditional programming languages, so this might be the sou= rce of the confusion.=C2=A0

For your specific use = case, I'd have done something like the following:

<= div><If =C2=A0"! %{HTTP:X-Real-IP} =C2=A0-ipmatch '192.168.0.0/16' =C2=A0|| ! = %{HTTP:X-Real-IP} =C2=A0-ipmatch '192.168.0.0/16'=C2=A0">
=C2=A0= =C2=A0=C2=A0ErrorDocument 404 "My awesome error"
</= If>

or maybe using <ElseIf>/<Else>.=

http://httpd.apache.org/docs/current/s= ections.html shows a little paragraph about "Nesting of sections&q= uot;, but I don't see any reference of your use case. I'll dig a bi= t more during the next days to find a better explanation if nobody will com= e up with a better solution :)
=C2=A0

It t= ook me a while (and I forgot to update the list) but I double checked and c= urrently httpd does not allow nested <If> sections. I updated the fol= lowing doc pages to warn users:


I am currently investigating = if=C2=A0http://home.apache.org/~elukey/httpd= -trunk-core-nested_if_blocks.patch solves the problem; if anybody = wants to help testing please let me know :) (you can apply the patch to the= latest 2.4.x branch cleanly and recompile).

Too soon, I found some corner cases that require = more work to get fixed. Will update the list once done for anybody interest= ed :)

Luca=C2=A0

--001a11443d18fa5072054be248a0--