Your patch will simply let the %2F through, but then a later section
of code will translate them to / and we've opened a security hole
in the main server. I'd rather move the rejection code to the
place where a decision has to be made (like the directory walk),
but I have no time to do it myself. I think it is reasonable to
allow %2F under some circumstances, but only in content handlers
and only as part of path-info and not within the real directory
structure.
is this a veto?
No, I'm usually very clear when I intend to veto things.
because i'd like to understand how this
'opens a security hole' available to client-side exploitation
without server-side deficiencies (such as a poorly-coded cgi
script). if there is none, i don't see why this cannot go
in as a starting point.
I don't know if it does or not, but to be sure you have to check
both the URI parsing code (to be sure it isn't ignoring changes to
the URI that would not normally appear with %2F..) and all of the
modules that do URI access control and rewriting. A better idea
would be that any URI with %2F be externally redirected to the slash
replacement, because you are changing the meaning of the URI
in a way that must be observed by the client.
....Roy
