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 2D4C5200C45 for ; Tue, 28 Mar 2017 17:28:47 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2BF05160B7E; Tue, 28 Mar 2017 15:28:47 +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 22A25160B89 for ; Tue, 28 Mar 2017 17:28:45 +0200 (CEST) Received: (qmail 62293 invoked by uid 500); 28 Mar 2017 15:28:44 -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 62132 invoked by uid 99); 28 Mar 2017 15:28:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2017 15:28:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 383F31A07A4 for ; Tue, 28 Mar 2017 15:28:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id AEXnfdG4a8Gl for ; Tue, 28 Mar 2017 15:28:42 +0000 (UTC) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id AACA65F253 for ; Tue, 28 Mar 2017 15:28:41 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id o81so1615499wmb.1 for ; Tue, 28 Mar 2017 08:28:41 -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=rQWtu8vtv056E8Y9cL/QZI1gZtA8BgAMGk3xyC0LkjQ=; b=E78McDUNe6jonu5ursTaDD+imb+faQHEqI1kNGcU1oM3AXhgqii3FuC6mu4ZDlJLDz 6EA7yoFUWB3nqtNSNh0YvKNXk7W9UZ19COiaUWome5cU3wBAbf9x/Yc7GA7IKDiQKLS/ fpVH0iGMDQfH8TpZ0n3beZm8qhHci8WtW9OmbhOcCYaAQGQrljn6cDywZiAiHraht7jD veeK4nfXL5J8+tyS67CrC3WNjos5TXukUpbRT9vUlezkyVj4D+ux5zn91IWbURXjA9jx LR47Ah3XPXSzvKoPHJFvss0cIW89v9sDPvwxRQqgXqbLegDxRvC4mA0CwidxAOidMZyO YzXg== 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=rQWtu8vtv056E8Y9cL/QZI1gZtA8BgAMGk3xyC0LkjQ=; b=bqWCeTLU5bGY4J/Ti0QyuGKX2ta8aIV3Jzm/sNM9qquuYbfG0a2pEN5xas40Iz8d/b KHTs4adeA/yW+6ULFpTTnunO6SNKhUhLzj/rb5dxItgGICd0x1G8dhBwloArTk6GqAI6 IHh01Su5SAbIkYBW5h0te9ZWkamHlKTgumnEKByhwf12gli/YnMwsNdd9+fDIztE/elO 0tCD4Iqfu4CqzfDsZdnZ3+b1Zt+l1mryLmXmP265Gh5HY+cVyOmT/4rAMdCX/ApUtcwq Re9r2jc5r3wB2L4owGHhT3se8yrSVR82wU+gbwtf2iWbcAa9CL9DvbZORQqdT3T2MAnU 0QDw== X-Gm-Message-State: AFeK/H3e//X/FxIhHhmY1oxRMS34qPm+p/Reqlah/pjA3UWgzkjItugmbCnZNA8HAY4Bslx/GPOd+5h+GiqUmg== X-Received: by 10.28.111.136 with SMTP id c8mr15029343wmi.128.1490714921156; Tue, 28 Mar 2017 08:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.149.1 with HTTP; Tue, 28 Mar 2017 08:28:40 -0700 (PDT) In-Reply-To: References: From: Luca Toscano Date: Tue, 28 Mar 2017 17:28:40 +0200 Message-ID: To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=001a1147c3e0564820054bcc1d9a Subject: Re: [users@httpd] Problem when using nested if statements in apache 2.4 archived-at: Tue, 28 Mar 2017 15:28:47 -0000 --001a1147c3e0564820054bcc1d9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 e= xternal >> users of our web site, while allowing staff to see the real error. The >> idea is to prevent exposing privileged information to the general public >> while allowing our staff to more easily debug issues on our production w= eb >> site. To accomplish this I am using a combination of ErrorDocument wit= hin >> an If statement that evaluates the header X-Real-IP which is the IP addr= ess >> 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.84= . >> >> >> >> 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 used= . >> >> >> >> 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 defaul= t >> 404 page. The IP does not match either of the ranges as observed when >> using the ranges individually, but when combined in this way it does not >> work as expected. >> >> >> >> Any ideas why this is? >> >> >> > > I reproduced your use case and from the error_log (trace8) I can see that > 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 o= f > how the ErrorDocument core directive settings are merged between sections= , > 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 use > 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). Thanks! Luca --001a1147c3e0564820054bcc1d9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 <m= schlott@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 took me a while (and I forgot to update the list) but I= double checked and currently httpd does not allow nested <If> sectio= ns. I updated the following doc pages to warn users:

http://ht= tpd.apache.org/docs/current/sections.html
https://httpd.apache.org/do= cs/2.4/mod/core.html#if ("Not a scripting language")

I am currently investigating if=C2=A0http://ho= me.apache.org/~elukey/httpd-trunk-core-nested_if_blocks.patch solves th= e 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).

Thanks!

Luca=C2=A0
--001a1147c3e0564820054bcc1d9a--