I took a peek at this. Basically, Joseph and the folks at Mozilla found that some odd quirk in FireFox is causing the bytestream to be sent with funny packet payloads of, mostly, 1 byte, 4095 bytes, 1 byte, 4095 bytes, etc. That seems to be a client issue.
What's happening is that occasionally, we get a 0 byte payload (as can be seen in a log Joseph posted at http://staging.sr.admission.net/joetemp/libapreq_debug_ff20_win32_https.txt). Once that happens, multipart_buffer_read returns 0 and ApacheRequest_parse_multipart breaks out of the data-reading loop for that parameter and starts reading line-by-line looking for the next boundary/header (which it may or may not find since we're treating binary data as text, so all bets are off). I'm not sure how we can hack around that (nor should we if it can be fixed) and my personal opinion is this is still FireFox's problem; not ours. I'll CC this to the bug report at rt.cpan.org and Mozilla's bugzilla. Issac Joseph Huckaby wrote: > Hey libapreq dev team, > > I recently logged a bug for Firefox 2.0 which results in corrupted > file uploads over HTTPS (Firefox 2.0 Win32 only). However, further > research seems indicate libapreq may be involved (I cannot > reproduce it outside libareq, for instance using PHP or the Perl CGI > module). If you have a moment can you take a look and see what you > think? Here is the Firefox bug report: > > https://bugzilla.mozilla.org/show_bug.cgi?id=356470 > > Thanks! I use your excellent Apache::Request module extensively in my > company's core software (Apache 1.3.x, libapreq 1.33), and we're not > sure what to do about Firefox 2.0. > > The bug appears to have to do with the way libapreq reads bytes off > the incoming socket. With Firefox 2.0 Win32 HTTPS occasionally it > reads 0 bytes, and then drops out of the loop and discards up to 200K > from the file being uploaded. It's all detailed out in the FF bug > report. > > - Joe > > Joseph Huckaby > Lead Software Engineer > AdMission Corporation > http://www.admissioncorp.com
