httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Nash <>
Subject Fixed: Truncated uploads in mod_perl 1 from FF2.0/Win
Date Mon, 09 Apr 2007 22:18:46 GMT
Hello, not long ago I ran into the bug described in these links:

After a lot of investigation, I'm pretty sure I've found what's happening.  
The problem is not quite the behavior described in the linked apache mailing 
list message, "What's happening is that occasionally, we get a 0 byte 
payload".  Firefox 2 for Windows is often sending single byte payloads (which 
is really dumb, but evidently should be allowable behavior), but libapreq is 
ignoring that single byte when it happens to be character 0A (a linefeed).  
This occurs in the function multipart_buffer_read in 
apache_multipart_buffer.c.  The 0 byte buffer read causes the loop that's 
reading the entire stream to break out.

I solved this problem by writing a one-line patch for our web servers.  The QA 
guys here have tested it and it works for every browser and OS we support, 
but based the following comment, I suspect this patch may cause strange or 
bad things to happen server-side if a form is submitted from IE on Mac:

>  note that we really just look for LF terminated lines. this works
>  around a bug in internet explorer for the macintosh which sends mime
>  boundaries that are only LF terminated when you use an image submit
>  button in a multipart/form-data form.

But anyway, here's the patch.  Use at your own risk!

--- libapreq-1.33/c/apache_multipart_buffer.c   2004-11-26 
18:02:03.000000000 -0500
+++ libapreq-1.33-patched/c/apache_multipart_buffer.c   2007-04-03 
17:00:19.000000000 -0400
@@ -247,6 +247,7 @@

     /* maximum number of bytes we are reading */
     len = max < bytes-1 ? max : bytes-1;
+    if (bytes > 0 && len == 0) len = 1;

     /* if we read any data... */
     if(len > 0) {

View raw message