Skip Menu |

This queue is for tickets about the libapreq CPAN distribution.

Report information
The Basics
Id: 24040
Status: resolved
Priority: 0/
Queue: libapreq
People
Owner: isaac [...] cpan.org
Requestors: JHUCKABY [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 1.33
Fixed in: (no value)

History Show all quoted text
  Thu Dec 21 14:17:44 2006 JHUCKABY [...] cpan.org - Ticket created
Subject: HTTPS uploads thru Firefox 2.0 Win32 are chopped off
Uploading a large (1 MB) file via a simple HTML form in Firefox 2.0 Win32 using HTTPS results in a "cut off" file on the server (about 200K short). Here is a test page to reproduce: https://staging.sr.admission.net/joetemp/file_upload.html I recompiled Apache::Request with the DEBUG flag enabled (in apache_multipart_buffer.h) and here is everything it logged while reproducing the bug: http://staging.sr.admission.net/joetemp/libapreq_debug_ff20_win32_https.txt Notice the last line: [Thu Dec 21 10:24:18 2006] [error] [client 10.40.9.22] [libapreq] silently drop remaining '254180' bytes That is approximately the number of bytes missing from the file. Also, the log contains TONS of "find_boundary" entries. I have also entered a Firefox bug about this, as I am not sure if this is a libapreq problem, or a Firefox problem. However, the bug is not reproducible using the Perl CGI module, or PHP. Here is the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=356470 libapreq-1.33 Perl 5.8.7 built for i686-linux Apache 1.3.37 Linux staging.sr.admission.net 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 i686 i386 GNU/Linux
  Mon Jan 08 04:56:26 2007 isaac [...] cpan.org - Correspondence added
From: margol [...] beamartyr.net
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. [See also https://bugzilla.mozilla.org/show_bug.cgi?id=356470]
  Mon Jan 08 04:56:28 2007 The RT System itself - Status changed from 'new' to 'open'
  Fri Jan 09 03:11:19 2009 isaac [...] cpan.org - Correspondence added
Fixed in libapreq-1.34 ----- Maybe in order to understand mankind, we have to look at the word itself: "Mankind". Basically, it's made up of two separate words - "mank" and "ind". What do these words mean ? It's a mystery, just as is mankind. --Unknown
  Fri Jan 09 03:11:21 2009 isaac [...] cpan.org - Status changed from 'open' to 'resolved'
  Fri Jan 09 03:11:22 2009 isaac [...] cpan.org - Given to ISAAC