Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4D3A034E.6030107@rowe-clan.net>
Date: Fri, 21 Jan 2011 16:06:06 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Please vote - how to handle AllowEncodedSlashes
References: <yua62ti15lp.fsf@kabuki.mynet>
In-Reply-To: <yua62ti15lp.fsf@kabuki.mynet>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/21/2011 12:20 PM, Dan Poirier wrote:
> How to handle?
> 
> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
> [ ] 3. backport the trunk behavior, but using a new option to avoid
>     breaking existing configurations that might depend on the current
>     behavior

You have me a little confused.  I actually believe we need to forward port
the 2.0 behavior, allowing people to retain the 'new' behavior in 2.2 if
they so wish (with the Decode option).

I believe more people than not are having problems with the new behavior,
and there are two POLA (pricipal of least astonishment) which are competing,
those not yet upgraded from 2.0 to 2.2, vs. those doing a minor upgrade in
the 2.2 line.  The 2.2 behavior is so radically different that it makes
more sense to clearly document the change in 2.2 CHANGES and ship the 2.0
behavior, since for most users the 2.2 behavior looks broken to them.