DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27327>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27327 tie content length of form fields posted with struts-validator maxlength attribute or alike Summary: tie content length of form fields posted with struts- validator maxlength attribute or alike Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] eventually, DOS attachs might move from syn flooding to the application layer as now seen for example by the decompression bombs (http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html). Therefore, the concept implemented in most current httpd's is to first accept anything of ANY SIZE and only afterwards (provided the server didn't blow up already with "out-of-memory" - see Bug 22633 [maxFileSize not reaching GUI in graceful way] and Bug 27143 [proactive management of low memory situations]) e.g. in struts-validator checking whether the received file size was acceptable increasingly becomes a problem for uninterrupted server operation. The concept of the future should be more proactive and optionally (configurable in web.xml) apply the following more restrictive policies: 1) only accept fields with permitted names 2) only accept forms whose total length is declared with Content-Length (mozilla already seems to do that for "Content-Type: multipart/form-data") 3) only accept fields whose length is declared with Content-Length (this allows even more detailed user feedback) This would allow to manage size matters from within the application: For example, the application could make sure that only one logged in user at a time can upload a 45 MB file while visitors not logged in cannot upload anything beyond 10K - thus preventing unmanageable out-of-memory exceptions. Especially policies 2 and 3 should be optional because the admin running the server should be able to decide whether legacy browsers not providing such information should be served or not. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
