httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 20295] - Uploading large multipart/form-data sometimes fails
Date Mon, 02 Jun 2003 14:39:47 GMT
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





------- Additional Comments From trawick@apache.org  2003-06-02 14:39 -------
>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?)

apr_wait_for_io_or_timeout() is supposed to return success when it is 
safe to write to the descriptor again

apr_file_write() on a pipe with a timeout is supposed to try to write data once
apr_wait_for_io_or_timeout() returns success...

>, which fails with error 11 (EAGAIN). 

if apr_wait_for_io_or_timeout() returns APR_SUCCESS but a subsequent attempt to
write gets EAGAIN, that is bogus

look in srclib/apr/support/unix/waitio.c...  maybe poll() is reporting that the
descriptor is writable when it really isn't?  maybe poll has to be called
differently for a pipe on HP-UX?

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

seems to me that doing this just serves to change the timing a little bit... 
apr_file_write_full() has to turn around and try to write the same data again...

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


Mime
View raw message