You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/05/28 14:08:13 UTC

DO NOT REPLY [Bug 20295] New: - Uploading large multipart/form-data sometimes fails

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=20295>.
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=20295

Uploading large multipart/form-data sometimes fails

           Summary: Uploading large multipart/form-data sometimes fails
           Product: Apache httpd-2.0
           Version: 2.0.45
          Platform: HP
        OS/Version: HP-UX
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_cgi
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: mark@faime.demon.co.uk


Apache 2.0.45
Perl CGI.pm (2.93) (where used)
O/S HP-UX 11 (HP-UX cvhp344 B.11.00 A 9000/782 2000406090 two-user license)
Compiler CC: HP ANSI C++ B3910B A.03.34

Note: This problem seems to be O/S dependent (HP-UX)

Attached is the summary of a posting to comp.infosystems.www.servers.unix:

I'm having problems uploading large binary files from a web browser
using Apache (2.0.45) on HP-UX 11.  It seems that small binary files
(around 15k) upload OK, but larger files (>15k?) are getting
truncated.

When using CGI.pm (2.93), this will result in the infamous error
message:
CGI.pm: Server closed socket during multipart read (client aborted?)

However, writing my own CGI client without the CGI Perl module, it
seems that Apache just stops sending the form data part way through,
i.e. data is truncated.  This seems to be an Apache problem and the
client browser used makes no difference (tested with IE5.0 on NT and
Netscape 4.8 on HP-UX).

I've not changed any of the tunable Apache directives from defaults,
hence there should be no throttling based on file size, etc.

Running the same version of Apache on Linux (x86) doesn't seem to
exhibit this problem.  I'm wondering if this is something funny with
HP-UX?   I've spent a couple of days searching Google and it seems a
few people have hit the above CGI error with Apache2 on HP-UX,
although there is never a solution.  For what its worth, the files I'm
trying to upload are binary Microsoft Excel about 17k in size.

I've had this problem for a while across the last 3 or 4 Apache 2
builds, but I'm getting pushed by my users to get the problem sorted. 
Before I go digging into the Apache source, has anyone got any ideas?

--

Responding to my own question...

I have had some limited feedback confirming this problem on other
HP-UX/Apache 2 installations.  Apparently reverting back to Apache 1.3
resolves the problem.

Digging deeper I have noticed the following:
in mod_cgi.c within the function cgi_handler(), it seems that the call
to apr_file_write_full() returns a non-successful return code part way
through writing the form data to the child process.  Apache then
gobbles up the remaining form data without trying to send it again. 
Some entries in the error log would have been useful here!

In the function apr_file_write() (unix/readwrite.c), it seems that
when apr_wait_for_io_or_timeout() returns success, Apache tries to
write more data to the fd (why?), which fails with error 11 (EAGAIN). 
I patched the code by returning success (and zero bytes written) after
a successful apr_wait_for_io_or_timeout(), which seems to solve the
problem in this instance.

There may be some #defines or something not setup properly for HP-UX,
although not defining USE_WAIT_FOR_IO at all causes the whole thing to
break on HP-UX.

Mark Street.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org