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=40598>. 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=40598 ------- Additional Comments From [EMAIL PROTECTED] 2006-10-27 07:58 ------- Created an attachment (id=19046) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19046&action=view) MaxLoops conceptual patch (In reply to comment #1) > So what you would need would be something like the option MaxLoop which of > course would be changeable via .htaccess again. But that would be a new > feature. And new features are very very unlikely to be introduced into 1.3. > So it makes more sense to propose this as an enhancement for the actual > trunk of httpd and hope that it gets backported to 2.0.x. Here is the hotfix we used for our servers. It uses a fixed loop count of 10. I was actually planning to make this value configurable and port the patch to HEAD then. However, as you mentioned the restriction could easily be overwritten by a customer within a .htaccess file. I was giving this some thought and came up with three halfway decent solutions. The first two introduce another additional "RewriteOptions": 1) "LockOptions" - values can't be set/overwritten by "RewriteOptions" directives later in the request processing. This would apply to all options (inherit, MaxRedirects, MaxLoops). Could easily be enforced in function cmd_rewriteoptions(). Maybe "LockOptions" should only be allowed in server context. 2) "LimitMaxLoops=n" - the MaxLoops value can't be set to a value greater n. "LimitMaxLoops" should only be allowed in server context. Customers would still have some flexibility (within the defined range 0-n) it they need to set MaxLoops in .htaccess. 3) Disallow to disable a "MaxLoops" restriction once set, e.g. the default "MaxLoops" value of -1 allows endless looping via [N] tagged rules. One can only set non-negative values (say 0 to 10000) in the config. Thus, once set, no one can disable the endless looping restriction. It would still be possible to extend it, though. I like 2) and 3) better since they just put the endless out of endless loop, letting admins sleep well and leaving customers some freedom. Would any of these approaches be good enough to get into HEAD? Or is that maybe generally rather hard? -- 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]
