httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: Possible bug in libapreq
Date Mon, 08 Jan 2007 09:56:23 GMT
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

Mime
View raw message