#Trace securesend login mac os x#
#Trace securesend login full#
#Trace securesend login code#

We're sending the full file contents to the server (an uninterrupted block of 1,185,483 encrypted bytes to the server, which would be the 1,163,446 bytes of the file plus 22,037 bytes of SSL overhead). The good news is that a nominal sniff of the problem (using 12-images.zip) shows that this sure seems like a server problem. I can't seem to reproduce this first freak sniff, so whatever caused it is probably something else. So, the bit about getting an unexpected SSL alert isn't what's normally happening. Ugh - I somehow managed to sniff a freak connection, and it's unlike all the other times I've reproduced the problem. Why 1MB files fail and 2MB files succeed!

Than the one sent, this makes me suspect that the code is not handling Given that the reported results are that the file transferred is shorter That might be OK for blocking NSPR sockets but not for non-blocking NSPR if the code only checked the return value for -1) If code assumed thatĪny return value other than -1 was equivalent to having written the fullĪmount requested, (i.e. 1 and the non-zero amount specified to be written. However a non-blocking NSPR socket may return any non-zero value between It returns either that fixed amount or -1, but no value in between. That is, when a write function is called to write a fixed amount, The sockets are blocking, but they are now non-blocking?īlocking NSPR sockets have the property that they never return short writes. Is it possible that the code for uploading those files assumes that The NSPR sockets used for file upload to be non-blocking, where they were Has there perhaps been a change that caused

This bug is NOT reproducible in the Mac OS X version of Firefox 2.0 RC2. The Content-Length header that Firefox is sending seems to be correct, so there must be something wrong with the file section of the multi-part HTTP POST request. Source code available on request: jhuckaby at gmail dot com. The Perl module used to parse the HTTP POST is Apache::Request version 1.33. My server-side script is using mod_perl 1.29 on Apache 1.3.37 under Fedora Core 4, i386 arch. The file size on the server should be the actual size of the file. My test file is 1163446 bytes, and with Firefox 2.0 RC2 it arrives on the server with size of 905215 bytes. See the results page which lists the file size under 'File Uploads', and it will be smaller than it should be. The bug only occurs in Firefox 2.0 RC2 Win32, and only under HTTPS. This same upload works fine in Firefox 1.5, MSIE 6, Safari 2.0, etc. When I upload a large (1 MB) file using a simple form and HTTPS, the file arrives on the server smaller (800K) than it should be. NET CLR )īuild Identifier: Mozilla/5.0 (Windows U Windows NT 5.1 en-US rv:1.8.1) Gecko/20061003 Firefox/2.0 User-Agent: Mozilla/4.0 (compatible MSIE 6.0 Windows NT 5.1.

#Trace securesend login full#

#Trace securesend login code#

#Trace securesend login mac os x#