Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Please vote - how to handle AllowEncodedSlashes
Date: Wed, 26 Jan 2011 16:52:05 +0100
Message-ID: 
 <E563FB5AB3F02844AC749BA39E494AB40410B787@VF-MBX11.internal.vodafone.com>
In-Reply-To: <ihpevc$6i6$1@dough.gmane.org>
Thread-Topic: Please vote - how to handle AllowEncodedSlashes
thread-index: Acu9br59oQOLgaXsR0K4zem5LFgV/AAAZnFw
References: <yua62ti15lp.fsf@kabuki.mynet> <ihpevc$6i6$1@dough.gmane.org>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

> -----Original Message-----
> From: Dan Poirier [mailto:poirier@pobox.com]=20
> Sent: Mittwoch, 26. Januar 2011 16:35
> To: dev@httpd.apache.org
> Subject: Re: Please vote - how to handle AllowEncodedSlashes
>=20
> On 01/21/2011 01:20 PM, Dan Poirier wrote:
> > Can we take an informal vote on how best to handle=20
> AllowEncodedSlashes?
> >
> > At present, AllowEncodedSlashes Off (the default) results=20
> in any request
> > containing an encoded slash, %2F, being rejected with a 404.
> >
> > In 2.0 and trunk, AllowEncodedSlashes On allows the encoded=20
> slash, but
> > does not decode it.  This keeps httpd from misinterpreting=20
> an encoded
> > slash in a request as a path separator.  I believe this was always
> > the intended behavior.
> >
> > In 2.2, AllowEncodedSlashes On allows the encoded slash,=20
> and decodes it.
> > This has caused problems for multiple people (see bugzilla, e.g. PR
> > 35256), but has been the behavior since 2.2.0 (introduced in
> > 2.1.something, I believe unintentionally).
>=20
> One correction for the record - 2.0 behaves like 2.2.  I doubt it's=20
> worth fixing, though.
>=20
>=20

But this changes a lot. If 2.0 is like 2.2 then nothing breaks for =
people
moving from 2.0 to 2.2. So we should fix in trunk and set it to a sane =
default
(whatever this is, see discussion in the thread) and the backport to 2.2 =
should
preserve the current behaviour and just offer an option to enable the =
trunk default.


Regards

R=FCdiger