DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35256>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35256 ------- Additional Comments From [EMAIL PROTECTED] 2007-09-20 01:31 ------- Voting early/voting often since I will not have a chance to look at this, this week. strong veto (-1)... I've watched jk try to do the same thing and I'm getting slightly tweaked about patches like this. Each hole you "close" is another hole you open up. Each encoded character has a meaning, skip a encode/decode ***or just as bad*** double an encode/decode and you pass things through to another application which can be equally harmful. I believe there are two sane ways to handle this, and it's never in urldecode. One is to represent, in an extended character set, the symbolic '/' and '\' as special-characters, while the textual (encoded) '/' and '\' become their text representations, exactly those symbols. Alternately, a series of '/' elements can be represented as path_elts segment by segment, with the textual '/' members in those patterns. The other is to provide remappings but NEVER on a global scale; it must be dealt with in a application by application basis. So I would consider, for example, a patch to handle this cleverly for PATH_INFO variables, but not a patch which affected all modules without thought. Rather than 'Don't decode "/"' I'd much rather see a patch 'map "/" as "%2F"', where the escape could be to "\x2F" instead, reducing the likelyhood of opening up new security holes where none existed before. That map could either address the issue of a "/" symbol or the encoded "/" text. Only ambiguous symbols could be allowed processing this way. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
