> -----Original Message-----
> From: Dan Poirier [mailto:[email protected]] 
> Sent: Mittwoch, 26. Januar 2011 16:35
> To: [email protected]
> Subject: Re: Please vote - how to handle AllowEncodedSlashes
> 
> On 01/21/2011 01:20 PM, Dan Poirier wrote:
> > Can we take an informal vote on how best to handle 
> AllowEncodedSlashes?
> >
> > At present, AllowEncodedSlashes Off (the default) results 
> in any request
> > containing an encoded slash, %2F, being rejected with a 404.
> >
> > In 2.0 and trunk, AllowEncodedSlashes On allows the encoded 
> slash, but
> > does not decode it.  This keeps httpd from misinterpreting 
> 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, 
> 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).
> 
> One correction for the record - 2.0 behaves like 2.2.  I doubt it's 
> worth fixing, though.
> 
> 

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üdiger

Reply via email to