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 34270] - Large POSTs over SSL from Internet Explorer do not complete successfully
Date Tue, 10 May 2005 14:21:01 GMT
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=34270>.
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=34270


david_arcuri@mgic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Additional Comments From david_arcuri@mgic.com  2005-05-10 16:20 -------

Further research yields more data:  TCP settings help mask the problem somewhat
but failures still result when posting > 40 MB files from IE via an SSL
connection.  The failure mode is interesting -- a script which reads the input
stream from <STDIN> by simply reading bytes until $ENV{CONTENT_LENGTH} is
reached will eventually be killed by mod_cgi because the data stream is cut off
before the filesize is reached and the script happily continues to read 0 byte
blocks for a few loops until it receives SIGTERM.  A script which reads until
the read() returns 0 bytes will "complete" when it sees the 0 byte block but
will result in a filesize less than $ENV{CONTENT_LENGTH} because at some point
in the transfer, one endpoint will close the connection before the file is
completely transferred.

These failures, at least in our test environment, result about 1 out of every 10
transfers.  Based on the relatively infrequent failure rate, I began looking for
likely culprits for variability in the environment.  Our "test" server is a Sun
E250 (Ultrasparc-II CPU 400 Mhz) which experiences the failures.  Our "qa"
server is a Sun E250 (Ultrasparc-II CPU 2x 300 Mhz) which also experiences
failures.  And our production server is an E6500 (Ultrasparc-II CPU 14x 400 Mhz)
and, still experiences failures.

On a whim, I set up our test environment on a Sun 280R (Ultrasparc-III CPU, 2x
750 Mhz) which is a faster, newer server with a much better pair of CPUs.  Over
about 80 tests I did not experience one failure.

I then reviewed what other steps we took to attempt to troubleshoot this problem:

1. Put the site behind an Apache proxy (mod_proxy) which halved the transfer
speed, but masked the problem -- no failures observed in this configuration.

2. Put the site behind a load balancer appliance (BigIP) which also somewhat
slowed the transfer speed, and masked the problem -- also no failures observed.

3. Turned on Loglevel debug in httpd.conf -- seriously slowed down the transfer,
but masked the problem, as every packet is being written to the error_log.

Because we are looking at only one thread handling the SSL decryption I have
considered that the old processors simply cannot keep up with the datastream and
some buffer, somewhere in the SSL code either inside Apache or in OpenSSL
(0.9.7g) is filling up and not being emptied correctly.  If the transfer is
bottlenecked somewhere else, this buffer isn't being filled.  The limit of my
troubleshooting capability has been exceeded at this point, so someone who knows
more about this process will need to take over.

I can provide as much information as is requested -- except an apache debug
session, as no failures are observed when this is on.


-- 
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message