Received: (qmail 96525 invoked by uid 501); 5 Apr 2001 15:16:49 -0000 Message-Id: <20010405151649.96523.qmail@apache.org> Date: 5 Apr 2001 15:16:49 -0000 From: Nigel Cole Reply-To: N.Cole@sc98c.demon.co.uk To: submit@bugz.apache.org Subject: Large Acrobat files fail to download into plug-in X-Send-Pr-Version: 3.110 >Number: 7527 >Category: os-solaris >Synopsis: Large Acrobat files fail to download into plug-in >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Apr 05 08:20:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: N.Cole@sc98c.demon.co.uk >Release: 1.3.19 >Organization: apache >Environment: Solaris 2.6, Generic_105181-20, Ultra Enterprise (two machines running as a high-availability server) gcc 2.8.0 Almost every file system bar /tmp NFS mounted from an Auspex file server Apache 1.3.19, 1.3.14, and 1.3.12 (to confirm it wasn't PR6711) >Description: This is not the same bug as PR6711, but may be related to PR 5457. When a large (about 1MB or more; it's not quite consistent, with an occasional 2MB file working and a 0.7MB file failing) PDF file is accessed via the Acrobat plug-in for Netscape Communicator, the following sequence takes place: 1. An initial request for the entire file; response code 200, but only some multiple of MMAP_SEGMENT_SIZE gets transferred (typically 32768). 2. A request with an If-Modified-Since header and a very long Range header; response code 304, no data sent. 3. A request for part of the file from about 100k characters in (variable); response code 206, rest of file sent. No Acrobat file is visible in the plug-in. The plug-in has no problem viewing the file if it is downloaded first and loaded from the local filesystem, nor has it any problem viewing the file from a Netscape Enterprise webserver on a different part of our network. Once the problem had been discovered, I did most of my testing on a vanilla 1.3.12 install, to make sure it wasn't caused by one of our non-standard modules or the problem noted in PR6711. The error log has a single entry, probably relating to the first request, claiming "Broken pipe: client stopped connection before send mmap completed". Sticking a lot of fprintfs in the code just confirmed that the write() system call was failing with a EPIPE error. Two different Solaris versions of Communicator were tried (4.51 and 4.74), with plug-ins for Acrobat 3 and 4 respectively. Another user has reportedly tried with NT versions of Communicator 4.74 and Internet Explorer 5.5, with the same result. My suspicion is some interaction between the plug-in, the socket code, and the code for handling ranges (the file downloads without any problem if Acrobat is launched as a helper application). I note that PR5457, which describes a similar problem, is also for Apache on an Sun Ultra running Solaris (though 2.5 rather than 2.6), so I also suspect that it's peculiar to Solaris. >How-To-Repeat: Our network is internal-only, unfortunately. It should be repeatable on a Solaris system with a sufficiently large PDF file, together with Communicator and the plug-in. >Fix: Sadly, no; I'm completely stumped at this point. There is a work-round (don't use the Acrobat plug-in, use Acrobat as a helper app), but it's not ideal. >Release-Note: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]