httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Please vote - how to handle AllowEncodedSlashes
Date Fri, 21 Jan 2011 20:22:05 GMT
On 1/21/2011 12:20 PM, Dan Poirier wrote:
> Can we take an informal vote on how best to handle AllowEncodedSlashes?

s/vote/poll/ :)

> 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).
> 
> All the doc, even in 2.2, reflects the 2.0/trunk behavior.

Whoops :)

> [X] 3. backport the trunk behavior, but using a new option to avoid
>     breaking existing configurations that might depend on the current
>     behavior

AllowEncodedSlashes should become a quad-state;

  Off    - Reject 404
  On     - Old 2.0 behavior
  Decode - New 2.2 behavior
  %nn[%nn...] - Replacement pattern for alternate encoding, which must
  "[string]"    be expressed in %-escaped form or quoted to distinguish
                between the first three forms (valid bool keywords and
                the Decode keyword).

The example could provide

# Defaults to off, set to On to preserve %2F, Decode to use '/',
# or choose a unique pattern to avoid path exploits directed at
# back end servers.  Note that either On or Decode can be very
# risky to back end servers, and may circumvent either httpd's
# or back end server access restrictions.  A third option to
# accept encoded slashes is to assign them to a special value
# which would not cause httpd or back end servers to treat them
# as special characters, as one example, for the private private
# unicode point F02F to represent %2f, enable
# AllowEncodedSlashes %ef%80%af

I would suggest we push for recognition of second-meanings of the basic
ASCII characters %00 -  %7F As unicode private code points F000-F07F,
and coordinate this allocation with the ConScript effort;
http://en.wikipedia.org/wiki/ConScript_Unicode_Registry


Mime
View raw message